List of API used in application?

[Gary Beene]

Some of the other threads got me to thinking - I'd like a tool which gives me a list of the API calls I use in my app.

PBCodec gives me a list of procedures, but only those I write.

Is there something that will list both my procedure and the API for me? It would be especially great if the list included the line numbers where they were used!

For that matter, I guess the same code that would recognize procedure calls would cover PB Commands, Macros, API, and custom procedures -that would most cool.

I haven't looked at the PBCodec source code. Does anyone know it well enough to believe it could be modified to do the trick?

[Michael Mattias]

Show exports and imports for PB/Win 6x, 7x (original by Torsten Reinow)

(may require some tweaks to compile w PB/Win 9x)

[Fred Harris]

Yes, that's a really neat program Michael clued me in on some time back. Haven't used it in awhile, but if I recall there may have been that 'Byval Required With Pointers' error or something fairly simple like that that needed fixed to run with PBWin 8.

[Chris Boss]

What you want is the Depends (yes, that is its name) utlity that comes with the Windows SDK CD. Depends will list all the external DLL's an EXE is linked to and the API's it calls.

[Gary Beene]

I looked at both suggestions (Depends and the referenced PowerBASIC code) and as best I can tell, they show every API - including those the compiler includes on its own (API I did not specifically call out in my source code).

I wanted a list of just the API I specifically call out in my source code.

Did I mis-understand how these 2 solutions work?

[George Bleck]

Let's answer your question with another question...

Whats the difference between a system API call and a function you create in an external DLL and call within you application...nothing.

There are no differences between calls to functions in an external DLL you wrote as opposed to a functions in Windows system DLLs. Only way I can think of to determine the difference is to have some sort of lookup table of known system DLL calls (or the flip side, your DLLs) so it can differentiate between your calls and system calls.

Remember, the Windows API is constantly in flux (new API's added with Service packs and OS upgrades as well deprecating functions). It's quite difficult to nail down a definitive list except for the most common API calls. It might be easier to create and maintain a database which details functions in DLLs you wrote and count all others as system calls.

[Dave Biggs]

One way to get a list of the API calls used in your app is to employ Börje Hagsten's inClean..
http://www.reonis.com/POFFS/index.htm

"inClean can create one lean include file containing all necessary
equates, declares, functions and subs from the following include files:
WIN32API.INC, COMMCTRL.INC, CMDLG32.INC, RICHEDIT.INC and MDI32.INC.
You can also replace DDT.INC, since it is a subset of WIN32API.INC".

As most of the API calls you make are via the declares listed in those #Include files (other than those you declare yourself or get with other #Includes) the reduced list of declares that inClean generates could contain almost all the API function names you are looking for.

[Chris Boss]

Gary,

The Depends utility program (comes with Windows SDK) does display only the API's explicitly linked in any DLL or EXE.

When you load an EXE into Depends, it displays a tree with all the depencies (DLL's). When you click on any dependency (DLL) in the tree, it will display two lists for the DLL.

The one to the right bottom displays "all" the API's in the DLL.
The one to the top right displays "only" the API's called by the parent item in the tree. For example if I click on say the gdi32.dll called by an EXE in the tree, it lists all the API's called by the EXE. Now if the gd32.dll has dependencies and I click one of them, the API's shown (top right list) are all the API's called by gdi32.dll and not the EXE.

This allows you to follow the "trail" of dependencies. The EXE calls a DLL, which calls another DLL and so on.

Depends will tell you all the API calls made by any DLL or EXE, as well as the calls made by any dependencies of the DLL/EXE.

Depends though won't be able to list any API's called via loading a DLL dynamically (LoadLibrary) and then called by its address (ie. call dword).

[Gary Beene]

After I started this thread, I had reason to make a list of the API that I think a new PowerBASIC programmer is most likely to need/use. I wanted to see how my first large app followed the list.

I understand that there are 1000's of such API, and that each programmer's needs are different, and that different apps focus on different API groups, and ... (lots of reasons why no one list is worth a hoot).

Still, a new PowerBASIC programmer needs somewhere to start. Hence my desire to create a list for inclusion on my website tutorials.

A PowerBASIC newbie could simply learn them one at a time, as the need arises - which is what I did. But since I knew there were 1000's to draw from, it took a while to realize that the every day "useful" list is much smaller and far less overwhelming.

And while I'm ranting on this particular topic, I have a similar story to tell about windows messages. There's the big list and then there's the most-likely-to-be-used list. You can guess which one of those I've also made up to include in my website tutorials.

And yes, I'll be posting both lists so the forum folks can help me make the list better! (well, or tell me why is list is woefully inadequate).

[Gary Beene]

Chris/Dave/George,

Sorry, I almost went off-topic there. But you can see why I wanted the list of API that I specifically call out - so I can help newbies understand what API they might most likely run across in some of their earlier apps. Dwindling a list of 1000's to 100's or 10's is a great way to keep a newbie from drowning.

I would guess that a PowerBASIC newbie who comes from another language that also used API extensively won't have this problem. In my case, I selectively used API in my VB6 apps whereas with PowerBASIC the use of API is pervasive - a good thing from my perspective, and my geek side actually enjoys it.

[Michael Mattias]

I would guess that a PowerBASIC newbie who comes from another language that also used API extensively won't have this problem

The problem these days is, I don't think a whole lot of "newbies" have ever seen an "SDK-Style" Windows GUI program which " used API extensively" .

This I think true if EITHER "newbie to programming" or "newbie to the use of the PowerBASIC compiler."

VB6 does not count as an "SDK-Style" GUI program, not at all.

And as far as calling the Windows' API from VB6 or any other language product... "reading the publishers documentation and converting CALLs and DECLAREs to PB syntax" is a required skill. It really does not matter if the publisher is Microsoft and the product the Windows' API or the publisher is some hardware manufacture with an interfacing API or a 'math' or 'communications' library you can pick up off of SourceForge.

MCM

[Chris Boss]

Gary,

Let me give you a personal experience.

I started learning PBWin (actually called PB DLL in those days) about 10 years ago. I was using PB DLL 5.0 at the time and there was no DDT then.

To be truthful, it was overwhelming.

Using the Windows SDK (API docs) I began to go through each control one by one. I started with the easier controls (listbox, combobox, button, etc.) first. Eventually I delved into the common controls. Later into building custom controls and even later into some more advanced stuff.

My initial reaction was "this is just too much"!

My response to all of this was, "build a library" of my own subs/functions to do all the hard stuff and make it as easy as possible to use. The library was originally called PBV (for PB Visual). You have to understand, at the time there was no DDT, no PB Forms, no Visual Designers for PB (MS Dialog Editor doesn't count IMO).

To make a long story short, this inhouse library eventualy became my commercial GUI engine which I sell.

In each new generation of my GUI engine, I had to deal with the question:

"What API's or Messages should I deal with first" ?

The answer is simple:

Ask yourself:

What common tasks would a programmer most likely need to do with a specific control or dialog ?

Don't think in terms of API's, but think in terms of tasks.

For example, with a Button control the tasks are quite simple at first.

The Button needs to respond to click events (mouse click).

Thats easy enough.

The Listbox control, one needs to be able to respond when the user selects a new item, for multiselect to determine which items have been selected, add items, clear the control, and so on. The basics. I then read the API docs to find how to do each of those tasks.

For most controls you will find that only a minimal number of API's or messages are required to do the most common tasks.

Think in terms of common tasks and then examine the API docs for solutions to those tasks.

Now once I was past the basics, things got a little harder because now I had to ask "what more advanced tasks would a programmer need to do with specific controls ?".

Going back to the button control, I started looking at what others applications were doing (no matter what programming language was used to create it). I noticed many apps with 3D colored buttons. I notice apps with non-rectangular buttons. Now I had more difficult tasks to find solutions for. This lead me to things like ownerdraw, regions, etc.

Still it was a matter of simply thinking in terms of tasks, not API's. Decide what tasks need to be accomplished first and then examine what API's will accomplish this.

IMO, writing low level API code for an entire program is a waste of time. Too time consuming. One should write reusable library code to handle common tasks to simply coding. Even if you prefer SDK style code, write your own libraries. The more high level the better.

For example, creating a Toolbar can require dozens of lines of code. In my own library it takes one line of code. I call function which I wrote (pure API code) which handles the task of creating the toolbar, defining the buttons, setting the bitmap, etc.

I have no idea of exactly how many API functions, COM calls, Messages, etc are in the Windows API, but I would venture to say it is in the many thousands. There is no way to learn them all, remember them all.

When calling API's (even messages) some require passing complex structures with many members, some quite confusing. There are different versions of these structures as well, depending upon the operating systems you target. There are ansi functions/messages and unicode functions/messages for the same task.

Some later additions to Windows use COM objects and that becomes even more complex and confusing.

Rather than be totally overwhelmed with the Windows API, simply think in terms of tasks you need to accomplish and then search out what API's handle the task.

You will find comments often here in the forums that the Windows API is easy to learn. Thats is simply not true (and not fair to all the newbies on the forums). Now it is worth it to learn the API. But you have to take it in "baby steps". Start with the easy stuff first. Once you grasp it well, then move on to more difficult tasks. It will be a "never ending story" though. There will always be new stuff to learn.

Because of my own experience, I strongly recommend using the provided GUI command set (DDT) in the compiler for new users. There will be plenty of time later to ask questions about "why" they do things a certain way and what API's DDT uses under the hood. Learning DDT will not hamper your understanding of the API later on.

You will find that DDT is not all the far from the API. Its not hard to figure out what API's or messages the DDT commands are using to accomplish their tasks. The advantage of DDT is that it is well designed and well tested.

The purpose of a programming tool is to accomplish tasks.
If you are task oriented you will find the best tools to use to accomplish your needs. For some it is DDT all the way. PB Forms has a strong number of users who are very productive with it. For others tolls like PwrDev or FireFly, give them the ease of visual design, but still use pure API calls.

But, do not be fooled into thinking that to be a PB purist, one must always use the Windows API directly. Productivity is the key.

First, be productive and let the compiler do as much for you as possible. later you can ask "why" and then delve into different ways to accomplish tasks. Experiment with the Windows API at your leasure.

[Michael Mattias]

I'm no fan of France, but let's at least learn to spell "niche" correctly, shall we?

This is not as bad as the "wahlah" we've seen here multiple times, but it's bad enough.

[Rodney Hicks]

Well said, Chris!
Every newbie should read that.
This quote:

It will be a "never ending story" though. There will always be new stuff to learn.

One should think of this as continuing education, an essential part of any profession and/or professional's career.

[Gary Beene]

Chris,

Thanks for the comments.

I'm a big fan of productivity - using tools that take the least time to get the most results. It's a no-brainer that DDT sometimes fits that bill and I plan to use it whenever it fits. When DDT doesn't give the result, then API are there waiting for me.

DDT has another useful feature - it can be visually short. I like visually short code because it can be much easier to review/debug. One page rather than 2-3 pages.

I actually enjoy the learning of API and the extra capabilities they offer, but when I'm writing a program it's usually the results, not the methodology, that counts.

Having said that, I can also see that once a person is particularly comfortable with API, that creating 1 line or 10 isn't such a big deal. Familiarity goes a long ways towards making multi-line code easy to read.
Another minimizing factor is that with good typing skills, as most of us have, the time to create extra lines isn't much of a factor.

The fact that DDT doesn't cover all situations and that some API usage will always be required actually paves the way mentally for leaning towards API in all cases but I'm still of a mind to mix and match at my discretion.

I still am concerned, or interested in knowing more about, any issues related to mixing and matching DDT/API. I'll need to re-read those to make sure I have clearly understood the concerns. As MCM noted, serendipity (things working by luck) isn't the approach I want to take.

None of my comments addressed the SDK-style windows - creating windows with CreateWindowEX API rather than the DDT engine. Once I've had some practice in that area, I'll weigh in, but for now I don't have the basis for an opinion.

[Gary Beene]

Chris,

I almost forgot to weigh in on your comment, where you thought API were not easy to learn.

... the Windows API is easy to learn.

I'd differ in at least one respect. In one sense, API are nothing more than functions that most programmers of every language are already familiar with. Whether they come from the Windows OS or from PowerBASIC Inc. doesn't really matter to the programmer as long as helpful documentation/examples for their use is ready at hand.

For example, these API could just as easily have been PowerBASIC functions as far as a programmer is concerned (yes, I picked trivial examples, on purpose).

    IsIconic - determine If Window is minimized
    IsZoomed - determine If Window is maximized

Yes, some API are much more complicated. Yes, the list of potentially useful API is very long and learning is an ongoing education. But the list of often-used API is finite, and very understandable. About the only real difference from my prior experience with Sub/Functions and the use of API is in the very frequent use of passing pointers to structures.

I don't want newbies to get the idea that there's some mysticism involved - that API are somehow above the ken of the average programmer. API usage does involve learning, but it's not rocket science (I built rockets and the associated electronics in my military career, so I do know the difference! <g>).

[Chris Boss]

Gary,

That was a typo !

It should have been:

"The Windows API is not easy to learn !"

Sorry about that. I am little tired today and doing a lot of paper work, so my hands are getting tired.

While some basics of the API are not awfully difficult, when one gets into some of the more complex aspects of the API, things can get very confusing very quickly.

To make things worse, the API docs were written for C programmers and not Basic programmers. There is always the need to keep translating things into a dialect Basic programmers can understand. For those who program in multiple languages (ie. Basic and C) it may not be as difficult, but for people like me who is a Basic only programmer, it "strains the brain" at times converting the API docs into Basic.

Many will take issue with my feelings on the difficulties working with the API, but I am not a newbie at this. I have at least 10 years of experience working with the API and my software shows this. I still don't like working with the API. I have to keep the Windows SDK (API docs) running at the same I am programming so I can keep double checking the API docs. I don't like stupid errors getting into my code because I used an API incorrectly.

This is why I encourage writing library code to handle common API tasks. Write routines which are friendly and call them rather than the API directly. Also PB is fast enough where you can add parameter checking in your routines to prevent errors from crashing your programs. Parameter checking is helpful because you can make it simply use default values if the parameters are incorrect or simply do nothing. You will more quickly see that something is wrong. Getting a GPF or having Windows do something wierd can be tasking on the brain.

For example in my GUI engine I made the choice to add a significant amount of parameter checking. I even test to see the class name of a window to make sure the requested action is valid (is it the right control type). The little extra overhead to do this, does not appear to slow things down at all.

You have to understand that much of my coding goes beyond the basics. I write custom controls myself such as a drag handle control, masked edit, vector and raster graphics, property list control, MCI control, etc.

I do a lot of subclassing and superclassing as well.
I do a lot with ownerdraw, regions, memory DC's, bitmaps, DIB's.

The deeper I get into the Windows API, the tougher it gets.
The API docs are also a bit cryptic at times and it is common to see errors in API code you find on the web.

One good example was when I was researching DIBsections. I noticed a number of code examples here and on other web sites where they called GlobalLock with the DIB's handle. At first glance it appeared to make sense and some good programmers were doing this.

It turns out all the code I saw was in error. You don't use GlobalLock on DIB's. Search MSDN for GlobalLock and CreateDIBSection. You won't find a single instance of MS using code like that.

If the programmers had simply tested the return value of GlobalLock when a DIB handle was passed they would have found out that it always fails, because the DIB handle is not a Global memory handle.

This makes even tougher, since you can't always trust the code you see on the web, even by experienced programmers. This is one reason I never just copy code I see on the web or these forums and use it in my software. I write every routine from scratch. I may learn from others code, but I just see what API's are used, then go back to the API docs and learn as much as I can about each API call and then write the code from scratch. I don't use an API call unless I fully understand how it works or the ramifications of using it. When you write commercial software you just can not take that risk. This keeps bugs down to a very minimum.

[Chris Boss]

Some tricks of the trade:

I use a number of utilities to help me do research as well as test software.

Here are some of the necessary tools in my toolbox:

Depends

This utility which comes with the Windows SDK is very useful. I can see what API's other software is calling. I can see all the dependencies my own apps load (remember a DLL may load other dependencies).

WinSpy

I use Borje's freeware WinSpy utility a lot. When ever I see an application and wonder "how did they do that", I use WinSpy to check out the class names of all the controls used by the app. This helps you to know whether they are using a standard windows control or some custom control (often an OCX).

Spy

This utility comes with the Windows SDK. It can display all the messages windows are getting in real time. This is very useful in seeing what is really going on.

Windows SDK CD

If you are really serious about working with the API, you must get a copy (download) of the Windows SDK. Windows API help files don't compare the depth of into in the SDK docs. Up until now I have been using the SDK CD from about 2001 since I try to make my software compatible with Windows 95 to XP. I recently downloaded a copy of the latest SDK and installed it on my Vista machine.

MsgBox

The msgBox command in PB (or windows API) is one of the most useful tools. When working with new API's I often use a message box to display the return values of the API's I used to see if they are failing or double checking return values of parameters.

BEEP

I use BEEP (PB command) all the time, in code where displaying a message box would not be possible. I can use BEEP to flag whether certain code was executed or not and with an IF THEN do tests. It is helpful to see whether certain messages are even occuring.

MsgBox and BEEP are my debuggers and you need real time debugging.

Internet (Google)

When dealing with strange results when calling the API, I often rely on Googling to find solutions. I figure if I get wierd results with an API that appear way out of the normal and if it is a quirk in Windows itself, then likely someone else has dealt with this. I often can track down posts on programming forums where they discuss some wierd problem in Windows.

[Gary Beene]

Dave,

Your tip was right on-thread:

One way to get a list of the API calls used in your app is to employ Börje Hagsten's inClean..

InClean was just what I wanted. It lists all of the direct calls my source code contains.

I had looked at InClean before, but at the time didn't really warm to its capabilities.

I have other source code that lists every unique text string (variable, procedures, strings - everything) and quantifies how many times they have been used. But a big app can have upwards of 10K unique strings, so InClean will let me quickly go to my list to see how many times I use each of the API.

Thanks!

[Cliff Nichols]

Gary from you initial comment

Some of the other threads got me to thinking - I'd like a tool which gives me a list of the API calls I use in my app.

PBCodec gives me a list of procedures, but only those I write.

Is there something that will list both my procedure and the API for me? It would be especially great if the list included the line numbers where they were used!

For that matter, I guess the same code that would recognize procedure calls would cover PB Commands, Macros, API, and custom procedures -that would most cool.

I haven't looked at the PBCodec source code. Does anyone know it well enough to believe it could be modified to do the trick?

Were you looking at ("Hey I have function "AddOne" but want to know that in the function I happened to call "GetWindow" from the api (or some other function)).....Sure logging your own functions is easy, but logging functions you call you did not write are not)

Coming from originall a VB6 side myself...some of your tutorials make more sense than the docs do when I think a concept is "SOOOOoooo Easy"....why the heck is it so hard to replicate??? part of the camps
Looking over all the forums over the years...I will be the 1st to admit that PB was my best way to "Test the temperature in the pool" rather than get shoved in and freeze.

I think I know what you were originally getting at. "Kinda compare SDK vs DDT" to show what the user was most comfortable with (Like PB code, vs pure API)

Quite a realms, but one worth taking on. (The docs on both sides are geared towards their consumer base, and if you do not understand all the docs it leaves you wondering )