Calling API
Archives Forums/MacOS X Discussion/Calling API
| ||
| Okay, so I've seen a few references to calling API functions by creating wrappers in C/C++ and importing those in my BlitzMax project. The problem is that at my shop, just adding BlitzMax to the mix is going to be challenging enough. Telling them we also have to have C compilers around is...well...I'd like to avoid it if at all possible. Is there really no way to simply import a header file or something and make direct calls to shared libraries? What I'm looking at specifically in this case, not that it matters much to this discussion, is GetNextProcess(). |
| ||
| Having a C compiler around is a requirement of BlitzMax - installing Xcode means nothing else than also installing GCC, so the C compiler will be there anyway. As for the GetNextProcess() question: This is systems programming, and therefor the natural domain of C and Assembler. In my opinion, writing C-wrappers for stuff like that is the only proper solution - on any system and any host programming language. I only took a very short glimpse at the documentation of GetNextProcess, but it seems that this function and its relatives accept a long list of parameters, of which many might not be directly translatable to BlitzMax's set of native datatypes. However that might really be, I definitely would only use it via a nice wrapper. |
| ||
| I disagree quite strongly that BlitzMax should require C wrappers around dynamic calls. That just doesn't make any sense, BMax is a very powerful language and there's no good reason that it shouldn't be able to make system calls directly. Calling OS APIs is *not* "systems programming". That's just writing a modern application on a modern OS. You have to call API functions, simple as that. GetNextProcess is a very simple function. The Pascal signature is: FUNCTION GetNextProcess (VAR PSN: ProcessSerialNumber): OSErr; Just a single number and another number passed back (I believe both are aliases to Long integers or a similar number). Getting the Process name from a serial number probably isn't that much more difficult. Why on earth should I have to wrap that in a function like:
int __GetNextProcess(int *ProcessSerialNumber) {
return GetNextProcess(ProcessSerialNumber);
}
That's just silly. |
| ||
| > That's just writing a modern application on a modern OS. You have to call API functions, simple as that. If calling API functions is modern programming, then I really wonder why people wrote all those OO frameworks to get away from it in the first place. > That's just silly. Yeah, but that it is what somebody actually did to get MaxGUI done, for example. If there is a simple way to call that API function, use it. If there is none, writing that wrapper to make it accessible on the BlitzMax language level will be the only fallback option. I honestly donīt know how the equivalent of calling a Windows-System-DLL works on a Mac or Linux. My job currently requries me to look into VPN solutions and database structures of a bigger project, so I donīt have to time to look into BlitzMax. If you figure it out, please post your solution here, so everybody can benefit. |
| ||
| An OO framework is just a different kind of API. No one writes entire programs beginning to end anymore, it's simply impossible. The bottom line is that BlitzMax should be able to call functions in DLL and SO files (Linux and mac) directly with a Declare Function ___ Lib "___" syntax. |
| ||
| example? |
| ||
| No one thought it was a good idea to mention Extern? Seesh. I'm not even going to bother to ask if anyone has used that on Mac. |
   |