It starts to bore me that I always have to ask questions about trifles.
I simply need a list of all plugged in USB devices and have the user select one to let the console application receive any data the USB device sends.
I can then start playing around with the data in my program.
I don't want to use library's, only standard C++ functions, and the program should work in Windows 98.
Here's something to get you started:
And for crying out loud update to an OS that's not from the last millenium. I hear Linux has great support for USB.
How can one write a program for USB, wanting to understand the background of it, while not wanting to read much about it, not wanting to use a library, all in the same time?
Anyway. there is a project "libUSB Win32" from Stefan Meyer not under heavy development at the moment, but written in C maybe this could be something for you, it has also the ability to run under ancient windows versions ;)
you can find it here:
http://sourceforge.net/apps/trac/libusb-win32/wiki
a while ago i have written this in VB6 that makes use of "libUSB Win32" don't know if it can be useful for you:
http://www.activevb.de/cgi-bin/upload/download.pl?id=3061
This is a very persistent question in forums and programming Q+A sites. Never with a happy ending. The B in USB means bus. That is a term in computer hardware design to describe an electrical interface for electronic devices to exchange data. It plays the exact same role as, say, the PCI (express) bus inside your machine. Since it is an electrical specification first and foremost, USB supports a very large number of types of devices. Anything from a wireless network adapter, modem, flash memory card to a teapot warmer. Just about the only kinds of devices that it doesn't handle well are ones that require a very large bandwidth, like a video adapter.
The USB specification has a very elegant protocol specification that describes how devices can share the bus and how they can exchange data. That protocol spec however does not describe the format of the data at all, it merely defines the notion of being able to deliver chunks of bytes. It is up to the device itself to give a meaning to those bytes.
On the machine end, you need software to interpret those bytes and make the machine do something interesting with them. That requires a device driver. Just like your video card and your network interface card require a device driver. Obviously a video driver is very different from a NIC driver. The same is true for USB drivers, there is little commonality.
If you want to write software that treats USB devices similar then you need to write that at the level where they still have something in common. That's at the USB controller level, you could write a filter driver that injects itself in the USB driver stack and peeks at the I/O request packets between the controller and the device driver. Similar to, say, the winpcap filter driver that spies on TCP/IP traffic. There isn't much of anything interesting to see though, you'd be staring at the blobs of bytes that pass back and forth. It is a much bigger problem than winpcap, at least it sees bytes fly by whose meaning is documented somewhere in an RFC. That's not the case for USB, the company that makes the USB device is also usually the device driver supplier. They keep the internal format undocumented.
Writing filter drivers requires pretty advanced skills, there are lots of pain points. Like crashing the operating system when you make a simple mistake. There has also been considerable flux in the Windows Driver Model lately, USB drivers have been getting moved into ring 3 (user mode) to keep the operating system stable.
To get started, download the Windows WDK (aka "DDK") and read Walter Oney's books. Preferably all of them.
I simply need a list of all plugged in USB devices and have the user select one to let the console application receive any data the USB device sends.
Getting the list isn't the big problem, it's receiving the data.
I know you don't want to write a driver, but this is what drivers do: receive data from a device.
To add to some good answers...
USB programming is not 'trifles'
First you have to learn how operating systems work and why they have drivers.
Unless you want to program an RS-232 port in DOS, you can't communicate directly with the USB ports, you have to communicate with the OS and the driver for the device you are interested in.