umm..
FFP code has nothing to do with shaders. It's certainly not written in a "shader language". It's written in a simplified form of Direct 3D code.. If you are talking about the "FX" format, it's just a simple way to set things like texture stage states and other variables called types.

For instance, in your FX file when you want to set the srcblend mode you just use:
srcblend=one;

in D3D C++ code this same command would look something like this:
d3ddevice->SetRenderState( D3DRS_SRCBLEND, D3DBLEND_ONE);

So the same applies to all the FF code you may see in effects files. It's just a simple way of setting d3d variables, called types.

Direct 3D has no internal distinction between regular D3D code and so called fixed-function effects...this is maybe difficult to explain, but think of the FF style "effects" as merely configuring hardware texture blending attributes.. this mean the hardware has specific hardwired functions it performs on textures-- you can tell it which ones to use in what order, but you cant program them. I believe on newer cards the FFP is actually emulated in the shader units, so maybe they dont even have a FFP (not sure about this, but it will be this way soon for sure).

What Fixed Function code cannot do is modify anything on the purely vertex or pixel level once something has been sent into the rendering pipeline (except in certain specif cases like per pixel dot3 bump mapping..which is a fixed function that does affect pixels data...but it cant take vertex data and interpolate it to pixels).

Direct 3D gives a lot of useful funtions for setting blend modes, etc, that dont need the "programmability" of shaders...so of course there will always be fixed functions. D3D is an API, a set of functons that makes accessing hardware easy. There will always be a need for standard fast functions for specfic task, like creating a texture from a file, or blending a pixel over another pixel in a set way. The API is NOT the hardware.. so ultimately why should care how it does what it does?