Server Help :: View topic - Quick Windows API question.

Server Help

Trash Talk - Quick Windows API question.

50% Packetloss - Tue May 03, 2005 2:42 am
Post subject: Quick Windows API question.

I've been learning some of the basics of the Windows API from http://www.winprog.org/tutorial/ and ran across some stuff I hadn't seen before.
One of which is the GlobalAlloc() function, is this function any different or more efficient than malloc()? Also the CreateFile() function, is this any different or more efficient than fopen(). Both functions can be found under the Reading/Writing Files section of http://www.winprog.org/tutorial/app_two.html

I plan on reading more and placed an order for this book at Borders Books (a book store that works with or is owned by amazon)
Programming Windows, Fifth Edition
I'm not sure if its any good but it will take them 2-6 weeks to even get it in and I am interested if there are any other great books that I should start off with. I don't want to read any MFC crap or .net bullshit. So any help you guys provide is great.

I'm also learning some OpenGL with this book
Beginning OpenGL Game Programming
So far it seems to be a good read. I don't plan on writting any games but maybe some subspace dev software in the very distant future. Any recommended books would be a great help aswell.

Mr Ekted - Tue May 03, 2005 3:38 pm
Post subject:

They are both lower level (closer to the operating system). malloc() is a run-time function that ultimately calls HeapAlloc()--similar to GlobalAlloc(). fopen() is a run-time function that ultimately calls CreateFile(). If you want to write machine-independent code, you use the standard malloc/fopen calls which are supported by virtually all forms of C run-time libraries.

GlobalAlloc() doesn't actually return memory. It returns a handle to virtual memory. This means that there are some blocks of virtual memory set aside for you, but that have not been committed for access yet. GlobalLock() takes the handle and forces the memory--if necessary--into real physical RAM, returning the pointer. If you want to use the Windows clipboard functionality, you need to use the Global* family of functions, whose handles can be passed across processes.

CreateFile() can do all sorts of things that fopen() cannot, like pipes, sharing modes, and overlapped I/O.

[edit]

I really should not be saying physical RAM because it's all virtual. Address 0x00400000 for process A is not the same physical pointer as address 0x00400000 for process B.

Cyan~Fire - Tue May 03, 2005 4:31 pm
Post subject:

Really, you don't need a book to write Windows code. I started learning from this. (I did have the "hard" copy in help form on my computer, though, which made it a bit easier.)

After you learn the basics and can make a window appear on the screen, check out some open source applications that use the API. For example, if you like AOK, check out my AOKTS source.

Mr Ekted - Tue May 03, 2005 4:41 pm
Post subject:

Tsk tsk. Not only returns in the middle of functions, but returns instead of breaks in switch statements!

50% Packetloss - Tue May 03, 2005 8:11 pm
Post subject:

Thanks ekted, do you know of any good books that I should purchase?

Mr Ekted - Tue May 03, 2005 8:31 pm
Post subject:

Understanding any aspect of Windows programming is much better with google than any book. You get good API reference, pages with overviews, and some sample code. The reference that comes with Visual Studio is pretty much vertabim from Microsoft's website.

Cyan~Fire - Tue May 03, 2005 10:46 pm
Post subject:

Mr Ekted wrote:

Tsk tsk. Not only returns in the middle of functions, but returns instead of breaks in switch statements!

Hey, I started this project a long time ago! It was originally in MFC, you can see how far it has (and I have) come since then... and you can see that I have fixed a few of the DialogProcs, etc. in terms of returns.

And yes, I agree that books are much less efficient than just using the help files and internet for programming. Every programming book I've read did nowhere near as good a job as the better websites on the subject.

xrestassuredx - Wed May 04, 2005 12:22 am
Post subject:

I occassionally run across a good book that actually does a good job of explaining things with decent examples. If you want to learn MFC, for example, Programming Windows with MFC (2nd Ed.) by Jeff Prosise is one of the best resources I have found, over googling for disparate and often inelegant code examples online.
As far as API programming, I try to stay on as high a level as possible (a software engineer's job description is to be lazy), so I can't help you there. If you are looking for books, though, go to a physical bookstore and look at the books you are buying to see how useful they really will be to you. You can usually find something that will work on google, but not always the "correct" or preferred solution to a problem that you would get from a well-written book.

Mr Ekted - Wed May 04, 2005 2:31 am
Post subject:

xrestassuredx wrote:

I try to stay on as high a level as possible (a software engineer's job description is to be lazy)

Nice flamebait....

Modern software engineers (ie 1995+) have been trained to use wrappers for everything (VB, MFC, STL, etc). Even C++ and Java are basically wrappers. Real design, efficiency, and flexibility of results are 2nd priority to making really quick shitty apps. They have diluted the field to the point where the average developer is now a retard who should be digging ditches.

The wrappers have accomplished their intended goal: more people can now engage in coding. I would compare this to script kiddies. Some real hacker puts in a real effort to make some hacking app. 10,000 people download this tool to "hack". They really have no idea what's going on. They just type commands or click buttons and have some fun. And if it doesn't work exactly right, they have no idea what's wrong. How would you feel if you were on an airplane at 30,000 feet and you found out that some VB flunky wrote part of the plane's hydraulic control system?

Dr Brain - Wed May 04, 2005 9:43 am
Post subject:

That's why CS people don't program embedded systems. That's what computer engineers are for. Programming hydraulic control systems.

SamHughes - Wed May 04, 2005 2:37 pm
Post subject:

Mr Ekted wrote:

[..]

Nice flamebait....

I half disagreed with your opinion, but then I realized that I think the same way when it comes to calculators being used in math classes.

I'm thinking of a nice way to torture Mr Ekted: Force him to read the questions asked on a PHP-oriented help forum! Full of priceless things like "How do I do such and such" where "such and such" is something that could be the first example in "Writing FOR loops 101". And some of these people will have customer data in a database!

Or force him to read classics like this one from somebody's CS II assignment:

Code: Show/Hide

{
long pikachu = 1;
if (squirtle == 5) {
/* Blah blah blah... blah blah */

pikachu = 0;
}

if (pikachu == 0) {
/* Glah glah glah... glah glah */
}

pikachu = 0;
}

And all of his variable names would be random irrelevent words that were usually professional "wrestlers" or pokémon or some other riffraff that had nothing to do with the task at hand.

Cerium - Wed May 04, 2005 2:49 pm
Post subject:

That guy needs to be set on fire...twice.
Once for knowing the names numerous pokemon, and a second time for using them.

Cyan~Fire - Wed May 04, 2005 5:00 pm
Post subject:

I see nothing wrong with writing your own personal "library" of wrappers that you can use in any application you write. But relying on something like STL and having no clue what's actually going on behind the scenes 1) will make your programming very inefficient and roundabout, and 2) will SUCK for debugging. (Debugging is the primary reason I stopped using STL.)

Naming variables with crappy names is the least of my worries. And of course the friend commented his code up the wazoo, I guess to make sure I understood everything OK.

xrestassuredx - Thu May 05, 2005 11:06 am
Post subject:

Mr Ekted wrote:

[..]
Modern software engineers (ie 1995+) have been trained to use wrappers for everything (VB, MFC, STL, etc). Even C++ and Java are basically wrappers. Real design, efficiency, and flexibility of results are 2nd priority to making really quick shitty apps.

No.. software engineer != programmer.

I say the job of the software engineer is to be lazy, not to ignore design and slap together something that kind of works, which is akin to saying someone who repairs the suspension bridge with duct tape is a mechanical engineer. What you described is a programmer, probably a CS major with a SE job description..

I'm "lazy" because it's in my best interest to reuse code that's already been written, utilize the standard libraries and to not reinvent the wheel any time I want to do something. That doesn't mean I don't know what's going on behind the scenes, how STL classes are implemented, etc, but I'm not going to program on the API level if it can be helped (and usually, it can).

Mr Ekted - Thu May 05, 2005 3:38 pm
Post subject:

Programmer is the entry level position, almost clerical. Here's a spec, do this. A software engineer takes an idea and figures out how it's going to work, how it's going to be put together, where the critical areas are, designs it. I realize this is all just semantics, but be careful what you call yourself depending on who you talk to; it might affect the way they evaluate your skills.