Quote:Original post by Flashthinker
Really? How would I go about invoking a native system API in Java? I knew that you can use external APIs as in not-built-in system APIs, or maybe I didn't word my question properly, what I meant by *external* APIs was "Native APIs" like those C++ invokes; Win32 and OpenGL, I noticed that in Java, I can only use Java-specific APIs like Java3D and JOGL, can I use true OpenGL though?

As noted, JNI is where to go. C# has Platform Invoke (or interoperability through C++/CLI), VBScript has COM support (and your COM objects can be written in C++), etc. At the end of the day, it's all machine code, and the processor doesn't care which source language was used to generate that machine code. As long as you've got the tools to splice things together, you're golden.

Quote:About your attack on my over-confidence, I never said that I was a "PRO" I just said that I "know" them as in; I am quite familiar with their structure and API. I do not know many advanced features. I only know what I need to know at this stage. I will look into what you mentioned though (about external APIs, not about my level of confidence :p)
I didn't mean to boast btw, I just thought it might give people common grounds on which to base their answers.

As noted, it wasn't meant as an attack per se. I've been programming for 16 years and I still don't "know" C++ (as evidenced by my performance on Washu's periodic quizzes). Problem is that to "know" a technology isn't a terribly descriptive thing - do you "know" it as in you've heard of it, do you "know" it as in you've been writing code in it for X years, do you "know" it as in you invented it, etc etc... I can see that this is something you understand.

Quote:
No, I was talking about the functions of APIs like the Windows API (Win32 is it?), I'm under the impression that the .NET framework is just a "reformating" layer that groups calls to popular system APIs in a more OOP manner.
Also, I have to admit, I don't fully understand how the .NET framework works, I'm going to do some research, but if you'd like to share your thoughts, I'd appreciate it.

It's more than just a wrapper - there's lots of stuff in there that doesn't have operating system components underlying it (for example, the database access components). In truth the .NET Framework is just one massive collection of libraries, some of which are self-contained and some of which are connected to external technologies like the Win32 API.

Also, re: Win32 - that's the nickname given to the 32-bit C API for Windows programming. Things like pointers are expected to be 32 bits in size. Under the 64-bit operating systems there are doubtless some functions that expect pointers to be 64 bits in size - these functions could be considered to be the 'Win64 API.'

At the end of the day, it comes down to this:

You've got a technology (like Windows). It does a whole bunch of things.

In order to have other technologies (like your application) interact with it, it needs to provide an interface for application programmers to work with it (an API).

Application programmers may be writing their applications in a great variety of languages and in a great variety of different build environments. Some people use Unicode. Some people are building 32-bit code while others are building 64-bit code. Etcetera.

You have to expose interface(s) to all the application programmers you want to allow to use your system. This does mean that your technology may have multiple APIs - for example, game engine The Nebula Device has APIs for C++, Python, Lua, and TCL (to say the least). Sometimes these APIs will exist side-by-side; other times you build one API on top of another (e.g. your Python API converts Python calls into C++ calls that then go through the C++ API).

Windows in particular exposes a second C interface at the other end of things, called the Device Driver Interface - as you may guess, it's an interface for device driver programmers to use to work with Windows, as opposed to applications programmers. Both the Win32 API and the 32-bit DDI (Win32 DDI) are exposing the same underlying technology - Windows - but in ways that make them more suitable to their respective users. The DDI gives you much lower-level data but (usually) in smaller chunks, while the API is higher-level and more oriented towards the tasks that Windows programs want to get done (for example, creating and destroying a window).

Quote:
And if you think that the API being procedural means you can't use it in C++, then you need to revise your definitions. Specifically, you need to consider that C++ is not an object-oriented language; it's a hybrid language that allows a number of paradigms, including both object-oriented programming and procedural programming.

Ok, thanks a lot :)
Things are much clearer now.I should note as well that you can write object-oriented programs in C. Object-orientation, procedural, functional... these things are all just programming styles. When we talk about an "object-oriented language," what we mean is a language that is 'friendly' to that particular style - has built-in support for the constructs, etc, such that using that style with that language may be easier than elsewhere.

OcaML is generally referred to as a functional language, but here's some OcaML code:

for i = 1 to 10 do
eprintf "%i\n" i
done

Looks procedural, no? Reads like a sequence of commands to be executed. The point is that while you can write procedural-style code in a functional language like OcaML, you'll find that you can't take advantage of many of the language features if you do so. Things like let statements don't really lend themselves to a procedural style.

It depends on the robot interface. Something like the serial port can be controlled directly in normal application code and if that's how you communicate with the robot you don't need a driver. You may interface with the robot through USB which probably will require writing a driver. Or maybe the communication is wireless so you make your own PCI card which can transmit wireless signals which Will require writing a driver.

The driver specifies the communication between the hardware and the higher level software. It depens on the hardware what kind of software you'll end up needing. If you want a pretty cheap way to start messing around with hardware you can look into programming a microcontroller (which is probably what would control a robot). There are kits out there for developers that you might look into someday. When I worked with microcontrollers I used HC12 and PIC18F based processors (in the later case the PICDEM FS USB demo board from Microchip, in the former case I forget exactly what we used). Something like the picdem would be a great way to start mucking around with hardware which is a lot of fun and relatively cheap(less than a new desktop computer, more than post card depending on how into it you get)

Quote:Original post by nobodynews
Something like the serial port can be controlled directly in normal application code and if that's how you communicate with the robot you don't need a driver.

Indeed - for some hardware, such as printer or serial ports, there's a sort of datapath between the API and the DDI - so you can feed your data to the port through the API and a standard port driver that sits between the DDI and the hardware.

Quote:You may interface with the robot through USB which probably will require writing a driver.

Actually, USB might not - XP provides an API for reading data from USB devices (the Raw Input API), though at a glance I can't find how to write data to a USB device. On other OSes - Mac OS X, for example - I know that there is a general-purpose API for reading and writing USB devices.

Quote:Original post by superpig
Actually, USB might not - XP provides an API for reading data from USB devices (the Raw Input API), though at a glance I can't find how to write data to a USB device. On other OSes - Mac OS X, for example - I know that there is a general-purpose API for reading and writing USB devices.

Well how about that? Thanks for the info. Maybe I'll try fudging around with an old web-cam whose driver never worked on XP.