I am currently writing some basic lightmap generation for terrain. It basicly works fine, but I want it to support objects with alpha transparency like trees, including that transparency.
That also already works fine, but now, everything without transparency doesn´t throw a shadow anymore.
The reason is bmap_lock, which returns 8888 for all textures. In this special case, most textures are saved in the mdl files and WED tells me that some are 24 and others are 32bit, which is exactly how it is meant to be.

And while I am at bmaps, a request: Is there anyway to allow at least pixel_for_bmap for dds files? Would be helpfull .

bmap_lock can return either 888 or 8888 for 24 bit textures, dependent on how they are stored on the 3D card. Some cards store textures always in 32 bit, regardless if they contain an alpha channel or not. bmap_lock has to return this value because the pixel functions need to know if the bitmap is stored in 24 bit or 32 bit format.

Pixel_for_bmap would not return anything useful for DDS files. They don't contain pixels, but image sections with palettes. But you could convert the DDS file into another format, like TGA, that contains pixels.

Okay, that makes sense.
Is there any way to find out if there actually was an alphachannel or not, or to make sure, that the alphachannel value is always >0 for such a textures pixels?
I could of course just check all pixels of a texture and decide that there is no alphachannel, if their alpha values are all 0, but I guess, that such an approach is quite slow.

Yes, with TGA images you can check this through the "bytespp" parameter of the BMAP struct. At 3, it's no alphachannel, at 4 it has an alphachannel.