Myths About Samba
~by Andrew Tridgell
There have been a number of press reports lately that discuss the
techniques used in developing Samba, and that refer to those
techniques as "reverse engineering". That term is quite misleading,
and does not at all accurately reflect the techniques that the Samba
Team actually use. I think that it is time to describe again the
techniques that we actually use, and to dispel some other common myths
about Samba development.
Myth 1: dissecting the waiter
Classical reverse engineering techniques in software engineering
revolve around the use of disassemblers, debuggers and other object
code analysis tools to examine directly the executable code of an
existing product in order to create a "clone" that behaves in the same
way. While these venerable techniques have been successfully used by
many groups, they are not what we use in the Samba project.
Apart from the fact that these techniques often lead to very poor code
in a new implementation, in the Samba Team we are very conservative
when it comes to techniques that might be legally controversial.
For people who aren't software engineers I usually use the "French
Cafe" analogy to describe the techniques that are really used in the
development of Samba. You can see the original French Cafe description
I suggest you go and read the French Cafe description now, then come
back, as the rest of this paper won't really make any sense until you
have read it.
I originally wrote that paper as part of a submission made by the
Samba Team to the European Commission Microsoft anti-trust trial. The
aim was to make the techniques used by the Samba Team more easily
understood by judges who might not be familiar with software
Extending that analogy a little, I think it would be fair to say that
classical reverse engineering techniques would be like taking a
scalpel and dissecting the waiter. It might indeed be possible to find
out how the waiter "works" from a biological perspective by using a
scalpel, but it is also possible to find out what you need to know by
just talking to the waiter, as long as you are persistent. The Samba
Team has been "talking to the waiter" for thirteen years now, and it
might be fair to say that we know more about his job than he does
For future reference, the terms we usually use to describe what we do
in developing Samba are "network analysis" or "protocol analysis". If
you see someone describing Samba as "reverse engineering" then please
ask them to use these terms instead, or point them at this paper.
Myth 2: which came first?
Many people incorrectly see Samba as being a "clone" of WindowsNT. A
quick check of history will confirm that the very idea is absurd. I
first released Samba in January 1992, whereas the first release of
WindowsNT was in August 1993. Unless you also credit me with inventing
time travel, it is difficult to see how I could have been aiming to
produce a "clone" of WindowsNT.
Furthermore, I didn't find out that Samba inter-operated at all with
any version of DOS or Windows until nearly two years after I did that
first release. The earliest versions of Samba were aimed at being
compatible with clients for the Digital Equipment Corporation
"Pathworks" product suite, which was an early implementation of the
SMB protocol that was quite popular at the time, and that ran on
Ultrix and VMS systems. My initial motivation was to implement the
same protocol on SunOS, so that I could use my desktop system to
access the departmental Unix server.
These days we obviously take great care to ensure that Samba is as
compatible as possible with current Microsoft Windows clients. That is
absolutely essential, as their monopoly market position in desktop
operating systems means that Samba is used with Microsoft clients more
than any other client. That doesn't mean we ignore other clients that
implement the SMB protocol, it just means that we test against
Microsoft clients more often than we test against other clients.
Myth 3: who invented CIFS?
Another common myth is to assume that Microsoft "invented" the
protocols that Samba implements. To understand how wrong this is you
need to know a little bit of history.
The protocol that Samba implements was first invented by Barry
Feigenbaum at IBM in early 1983. He initially called it the "BAF"
protocol after his initials, but changed the name to "SMB" before the
first official release. You may note that the name "Samba" contains
the letters "SMB", and that is not a coincidence.
The term "CIFS" or "Common Internet File System" was coined by
Microsoft in 1996 as a marketing exercise in an attempt to combat a
perceived threat from Sun Microsystems after their WebNFS
announcement. The term caught on, and now the SMB protocol is often
called CIFS. The two names refer to the same protocol, as is easily
demonstrated by connecting a current Microsoft "CIFS" client to a
Samba "SMB" server from 1992.
It should also be noted that SMB/CIFS is an evolving protocol. The
original design by Barry Feigenbaum deliberately allowed scope for
protocol extensions, and a number of groups have taken advantage of
this over the years. The largest set of extensions have been made by
Microsoft, but some quite substantial extensions have been made by
other groups, including SCO, Thursby, IBM, Apple and the Samba
It might be worth noting that of all these extensions, only Microsoft
has kept some (but not all) of their additions secret. It is also
important to note that in many cases Microsoft clients do not operate
correctly with servers that do not implement the Microsoft
extensions. That is, fundamentally, why we need to use the "network
analysis" techniques described above.
From 1996 until about five years ago Microsoft played a leading role
in the effort to standardize the SMB/CIFS protocol. They started the
annual CIFS conference series that continues today, they started the
effort to create an IETF standard for the protocol and they ran a
public discussion list on all aspects of the protocol. For reasons
that we still don't fully understand, they have since withdrawn from
all of these activities, and now appear to be actively hostile to open
Despite this change of heart on behalf of the biggest player, the CIFS
conferences and plug-fests have continued with the help of the Storage
Network Industry Association, and with the Samba Team playing a leading
technical role, alongside industry heavyweights such as Network
Appliance and EMC.
Where to now?
I still hold out hope that Microsoft will someday rejoin the SMB/CIFS
developer community by attending the annual conference and
plug-fest. A lot has happened since they stopped attending, including
the development of a comprehensive test suite that covers most of the
protocol. Microsoft is doing its customers a great disservice by
ignoring the opportunity to work with other industry members, and
could certainly benefit from attending the plug-fest and learning
about the extensive protocol test suites that are now available.
If anyone from Microsoft is reading this, then I encourage you to look
at http://www.cifs2005.org/ and seriously think about sending someone
with the technical knowledge to discuss what has been happening in the
last few years.
Andrew Tridgell (tridge at osdl.org)