Microspeak: FCIB

FCIB (pronounced either by spelling it out F-C-I-B or as a sort-of acronym eff-sib) stands for "foreign checked-in binary". It refers to content checked into a project as binary output, rather than as source code.

For example, a photo management project may use a facial recognition module provided by a team in Microsoft Research. There are few different ways this can play out.

One way is for the facial recognition team to provide source code drops to the photo management project. The photo management project checks that code into their project and compiles the source code and incorporates it into their program.

Another way this could be done is for the facial recognition team to compile their own source code and send either object files or complete DLLs to the photo management team. The photo management project checks those object files or DLLs into their program ("foreign checked-in binaries") and links it into their program.

The term FCIB didn't originally mean "foreign checked-in binary". According to legend, a component was being added to a team's project as a checked-in binary, and the development manager in charge of the project is reported to have exclaimed in frustration, "Not another f—ing checked-in binary!"

Thus was born the acronym FCIB.

Initially, the term FCIB was used internally within the project, but eventually they had to explain this acronym to others, and that's where the sanitized version came in.

Bonus history: The Ancillary Function Driver is called AFD.SYS, but that name is also a sanitized version of its original name. When the networking team realized that they had to add a kernel-mode driver to Windows, the development manager is reported to have replied, "What? Another f—ing driver?"

Comments (15)
  1. Richard B says:

    Don’t forget Larry Ostermans own contribution, bowser.sys, so named because his boss thought it ‘was a dog’. https://blogs.msdn.microsoft.com/larryosterman/2006/03/14/fun-with-names/

  2. Smithers says:

    Such censored backronyms remind me of the Android logging API, wherein one logs errors with Log.e(), warnings with Log.w(), etc. The highest level (for conditions that should never happen) is called ‘What a Terrible Failure’, but I doubt that’s the phrase on the programmer’s mind when they type Log.wtf().

    1. Antonio Rodríguez says:

      TheDailyWTF.com (which I’m sure many of you read) started with the original mean of “WTF”. But after a time, it changed to “Worse Than Failure”. In fact, many (most?) of the stories of that site are cases of terribly successful projects that barely reach release, and use to create more problems that they solve – its “success” being actually worse than a failure.

  3. Erik F says:

    Does this happen a lot at Microsoft? Are there any standardized rules regarding when to use external code and data? I can see executables based on a particular version of code, or code that crosses a Chinese Wall getting this treatment; is this what you were mostly talking about?

    1. James Moore says:

      There’s also code which uses exotic and unusual build processes which tend to result from research. Looking at our projects, I can completely anticipate other teams wanting a binary and an API rather than trying to figure out our build and then whatever they’d have do to make our build part of their build.

      In the example above, the photos guys don’t really care how facial recognition works, and they’re sure not going to be modifying the hyperparameters or retraining, so the source doesn’t do them much good.

    2. cheong00 says:

      I think there are “application grade” programs that comes with Windows and use MFC libraries (say, msinfo32.exe), these certainly qualifies as FCIB, right?

      I wonder if other team need shell functions, are they added as FCIB or not.

  4. Does Microsoft have an internal Nuget repository to deal with these issues?

  5. Yuhong Bao says:

    This reminds me of ctl3d32.dll or the Indeo codec.

    1. Not sure what your point is. Are you going to tell the story? Or is this just saying “I have an interesting story” but never telling it?

      1. Yuhong Bao says:

        I am talking about examples.

        1. Ian Yates says:

          In that the Intel Indeo codec is shipped with Windows but, presumably (because you’ve kinda said so), Microsoft doesn’t compile the codec but merely includes it as a FCIB and then a Foreign Shipped Binary.

          We all do this to a fair extent. Imaging libraries are very common. Any controls & toolkits we developers buy from third party vendors tend to be this way too. We don’t have the source, and probably don’t want to, or can’t, build their code anyway. We also pay for support and outsource the code precisely because we get a versioned “thing” that we can count upon.

    2. xcomcmdr says:

      That reminds me that I could not decode an Intel Indeo 4 video on Windows Vista or newer.
      Not Intel Indeo 5, which is still shipped with Windows, or even available on the Web, Intel Indeo 4.
      ffmpeg/ffdshow “decodes” it, but it’s output is useless.

      I had to use a Windows 98SE machine to capture the video. Win9X has a DirectShow codec bult-in for IV41.
      Alas, no VfW codec either….

      I wonder in which dll it resides on Windows 9X, and why it became totally unavailable, even on the Web ?

  6. Chris Crowther says:

    I loathe FCIBs in my source control; I’ve resorted to maintaining an internal NuGet server and turning the various FCIBs in to NuGet packages just so I don’t have to check them in. It works pretty well as a solution (probably until the day it doesn’t and then I’ll curse it).

    I really like having an easy way of saying “binary that wasn’t created by this solution’s build process” now :)

    1. Nick says:

      Same, except that we were already maintaining an internal NuGet for sharing service contracts

  7. alegr1 says:

    I’d think it’s YAFCIB

Comments are closed.

Skip to main content