decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books


Groklaw Gear

Click here to send an email to the editor of this weblog.

You won't find me on Facebook


Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

Myths About Samba by Andrew Tridgell
Sunday, February 06 2005 @ 11:04 AM EST

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 at:

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 engineering techniques.

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 himself.

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 Team.

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 standards efforts.

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 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


Myths About Samba by Andrew Tridgell | 231 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections here please.
Authored by: Erwan on Sunday, February 06 2005 @ 11:14 AM EST
If required.


[ Reply to This | # ]

Myths About Samba by Andrew Tridgell
Authored by: Ninthwave on Sunday, February 06 2005 @ 11:14 AM EST
Thank you, though I have read your documentation and articles fairly regularly
since my first Samba install in 1998 it is nice to hear your voice in another
forum as so many people in general are forgetting the standards bodies and their
work in making this fun loving gadgets work. So many time I talk to people and
they think hey isn't that a Microsoft idea and you try to explain it to them and
they don't care or don't believe you. I just don't understand how a technology
so pervasive in society, has so little understanding by the people who use it.

I was, I am, I will be.

[ Reply to This | # ]

Off Topic Links and Discussion here.
Authored by: Erwan on Sunday, February 06 2005 @ 11:18 AM EST
As usual...


[ Reply to This | # ]

Strange definition of reverse engineering
Authored by: Mouse on Sunday, February 06 2005 @ 11:51 AM EST

Reverse engineering means figuring out how something is designed based on how it's implemented (i.e. the reverse of engineering). I've never before heard that "reverse engineering" only refers to dissecting a program's internals byte by byte. Andrew Tridgell's description of how Samba was developed sounds like a perfect example of reverse engineering to me.

Maybe I've been doing it wrong all these years.

[ Reply to This | # ]

Myths About Samba by Andrew Tridgell
Authored by: Anonymous on Sunday, February 06 2005 @ 11:55 AM EST
That was a great historical accounting of Samba. I know next to nothing about
Samba and would like to learn more. Can anyone suggest a good beginners' guide
so I can get my Linux box and my Win2k box to talk with each other?



[ Reply to This | # ]

Reverse engineering
Authored by: emebit on Sunday, February 06 2005 @ 12:28 PM EST
My definition for reverse engineering is: The act of figuring out how something works.

[ Reply to This | # ]

Thank you Andrew
Authored by: fuego451 on Sunday, February 06 2005 @ 12:41 PM EST
Thank you for the interesting and informative article Andrew.
Though I've been using Samba on my home network for seven years
so my two Debian boxen can share files and printers with my
wife's Windows box, I wasn't completely aware of how it was

I will never understand Microsoft's stubborn determination to
be the company that everyone loves to hate. In a recent email
to corporate customers, Mr. Gates warns that those seeking
technological 'interoperability' won't find it with FOSS. Mind
bending double-speak, to say the least, but just another of
many catch-phrases Bill and company like to use. Other notable
examples are "We welcome competition" (as long as there isn't
any?) and "Freedom to Innovate" (for Microsoft only?).
Perhaps we should start a list.


[ Reply to This | # ]

Thanks Andrew
Authored by: shareme on Sunday, February 06 2005 @ 12:53 PM EST
Thanks Andrew,

A very well thought and factual response and entertaining as well as

Sharing and thinking is only a crime in those societies where freedom doesn't

[ Reply to This | # ]

SAMBA extensions to the protocol
Authored by: Anonymous on Sunday, February 06 2005 @ 02:03 PM EST
"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 Team."

I've occasionally read, in the Samba general mailing list and elsewhere, that
there are bugs in Microsoft's implementation. And now I see that the Samba team
is not just reimplementing the protocol, but extending it as well.

My idle daydream is that SAMBA would be able to operate in "Samba-only
mode" to avoid bugs and take advantage of features that are not available
in Windows... Then, of course, the next step is a Samba port to Windows. :-)

[ Reply to This | # ]

Authored by: Anonymous on Sunday, February 06 2005 @ 02:20 PM EST
Isn't this another example of Microsoft's Lock-in strategy?

When one buys and installs a PC one expects it to work on a network, often a
mixed network. Therefore when one buys a Server one expects it to serve to any
machine requesting a service.

What Microsoft try to do is, if you buy ONE MS machine, then ALL your machines
need to be MS in order that the network can work well (for quite small values of

A thousand thanks to Andrew Trigell and his team for a major assist in breaking
this lock-in.

[ Reply to This | # ]

  • OOPS! - Authored by: davcefai on Sunday, February 06 2005 @ 02:22 PM EST
  • Yes it is - Authored by: Anonymous on Sunday, February 06 2005 @ 03:04 PM EST
Myths About Samba by Andrew Tridgell
Authored by: Anonymous on Sunday, February 06 2005 @ 02:56 PM EST
I'm wondering how long will it take for Microsoft to start adopting some sort of
encryption for their SMB sessions...

I'm even more wondering why they didn't do that already.


[ Reply to This | # ]

Myths About Samba by Andrew Tridgell
Authored by: Anonymous on Sunday, February 06 2005 @ 03:06 PM EST
I am not a rocket scientist, but does this mean that if Ms or whoever developed
a protocol that they own the 1's and 0's happens to pass through my computer?

[ Reply to This | # ]

Reverse Engineering - but of what.
Authored by: rongage on Sunday, February 06 2005 @ 03:11 PM EST

First of all, I am very thankful for the work produced by the entire SAMBA team.

I believe that this "French Cafe" analogy is indeed reverse engineering. The (critical) difference though is in scope of work. In other words, they are reverse engineering the protocol and not caring one bit about the product behind the protocol.

I've done simular reverse engineering work on Allen Bradley Programmable Logic Controllers. The scope of my reverse engineering was quite limited to the protocol used by these devices - I had no intention of taking one of these $9000 things apart just to understand how it talks. By using Ethereal and some very limited but publically available documentation, I followed almost exactly the same methodology that Tridge uses - I studied the communications traffic between a PLC and a programming terminal to decipher, decrypt, reverse engineer, understand it. The end result is now there are freely available software products available for Linux where before there were none.

The point is: reverse engineering doesn't have to involve a physical product. Reverse engineering is a methodology of discovering the underlying facts about something.

Ron Gage - Linux Consultant
Pontiac, Michigan

[ Reply to This | # ]

Myths About Samba by Andrew Tridgell
Authored by: groovemaneuver on Sunday, February 06 2005 @ 04:06 PM EST

A lot of you have mentioned that the Samba team's "French Cafe" method is in fact reverse engineering, and while I technically agree, there is an important distinction. Decompiling a binary could land you in DMCA hot water (in the US) while the "French Cafe" method will most likely not. They're reimplementing techniques used by MS systems without doing anything other than watching and listening.

just my $.02

Chris Stark - Linux User, Musician, & Grad Student

[ Reply to This | # ]

Myths About Samba by Andrew Tridgell
Authored by: Anonymous on Sunday, February 06 2005 @ 04:20 PM EST
Actually, I believe, SMB (server message block) is used in alot of networking protocols. I believe Banyan Vines even used it, but its been years since I seen the spec. However, I don't see Banyan Vines documented in the Samba History either.

Anyway, its amazing how many people think Microsoft has invented great things. When it really boils down to MS's "embrace and extend" mantra. They embrace open standards then extend them into the proprietary realm, and leverages that with their Desktop monolopy. Bill Gates email, I believe this is a sign that they are losing in the server market. XML is the next big thing, Microsoft is scared. The way billg writes this email, he makes it sound like MS invented XML. ByteEnable LinuxElectrons

[ Reply to This | # ]

Reverse Engineering is just about programs
Authored by: Anonymous on Sunday, February 06 2005 @ 04:26 PM EST
In the real computer landscape, reverse enginnering comes in many forms. Whether
ripping apart programs to see how they work, or examinating how the motherboard
talks to the hard drive, reverse engineering isn't restricted to software.

On of the most commonly used forms of reverse engineering in computers is
network/protocol analysis, where you used a program or driver to eardrop on the
network, or on data stored in memory or on a disk, so you can determine what a
specific program is doing with it. This is how many of the "instant
messaging" programs that are compatable with yahoo/messanger obtained their

As a working example, recently I wrote a program to act as a dummy http proxy so
I could determine what a flash game was sending out to a website (I wanted to
cheat), After finding out what the game was sending out, and that what was sent
back could be ignored, I was able to write a little program that mimiced the
original flash game, without having to reverse engineer the original flash game.
But I did have to reverse engineer the network data to determine what the game
was sending based on the behaviour of the game compared to the network data.

Samba want to call what they do "network/protocol analysis" for
publicity reasons, but have failed to realize that their "network/protocol
analysis" is just one of many forms of reverse engineering with a fancy

[ Reply to This | # ]

Myths About Samba by Andrew Tridgell
Authored by: Nick_UK on Sunday, February 06 2005 @ 04:30 PM EST
Good read Andrew.

I really loved your quote from 'The Rebel Code' by Glyn
Moody (isbn 0-7382-0333-5):

"...And we try to remain bug-for-bug compatible where it
makes sense. There are some cases where it doesn't make
sense, and their bugs are just ridiculous, and you
shouldn't emulate them. But in most cases, we emulate the
bugs so that we interoperate completely with Microsoft

I have since treated all MS applications guilty before
innocent in similar context.



[ Reply to This | # ]

Andrew Tridgell Gets it Wrong
Authored by: WildCode on Sunday, February 06 2005 @ 04:40 PM EST
Reverse engineering isn't restricted to software, and isn't restricted to
ripping things apart.

Although most people think of reverse engineering as ripping something apart to
see how it works, most times reverse engineering is just analysing what
something does to determin how it works, without ripping it apart.

The later is what Andrew Tridgell wants us to call "network/protocol
analysis", possably for publicity reasons, but he has failed to understand
that "network/protocol analysis" part of the many aspects of reverse

[ Reply to This | # ]

Disassembling code vs. Data Analysis
Authored by: talexb on Sunday, February 06 2005 @ 05:13 PM EST
I did some serious data analysis in a job I had years ago, when I had to provide
a Word Perfect 5.0 file conversion tool. It involved staring at hex dumps of WP
5.0 files until I figured out out what was what. It was quite successful -- and

Certainly, that was different than loading the WP 5.0 program into memory then
using debug to make a dump of the memory image so I could follow the program as
it executed. But it seems to me that both are reverse engineering, even if the
latter technique is much more blatant.

[ Reply to This | # ]

Definition of reverse engineering
Authored by: Anonymous on Sunday, February 06 2005 @ 05:21 PM EST
I'll admit, I'm not quite sure whether people are just being argumentative for
the sake of it, astroturfing, or genuinely believe what they are saying about
reverse engineering definitions.

Here's the bottom line:

Reverse engineering is the process of finding out how something is engineered;
how it is constructed so that it can do what it does.

If company X makes a car using a combustion engine, and I make a truck that
relies on a series of pullies and a lot of people sat in the back peddling like
stink, they still travel on the road in the same way. The internals don't
matter, but the action does. This is the Samba way of doing things, to see what
something does and make something new that acts to the same effect. It's doesn't
have to, nor frequently should it, do it in the same way.

If I were reverse engineering that car, however, I'd take the thing apart,
figure out how it did what it did, and then make a new car that had a combustion
engine too. They'd act in the same way, because I'd copied the way it was
constructed, because I'd found how it was constructed in the first place.

Can we please give the bloke credit for actually knowing what he's talking
about, and what things semantically mean in the setting in which he has chosen
to work for 15 years of his life, and knows more about anyone else, and
assuredly has obtained plenty of professional and legal opinions?

Thank you.

[ Reply to This | # ]

OT: Canopy vs Yarro, and SCO vs IBM
Authored by: Anonymous on Sunday, February 06 2005 @ 05:44 PM EST
I have been reading the Canopy complaint against Yarro et al. SCO vs IBM is not
mentioned, but I think there is a connection.

My theory was always that McBride conned Yarro into approving the suit against
IBM. That is because it seemed to me that Yarro would not gain much if the scam
succeeded and IBM bought out SCO, but Yarro would lose a lot if IBM fought the
suit and found out that Yarro had approved a scam. It didn't make sense for
Yarro to agree to this, so I thought McBride had fooled Yarro into believing IBM
really had stolen SCO's code.

But now I read in the Canopy complaint that Yarro had a bonus agreement where
Yarro gets a lot of money if Canopy makes a profit from some deal. So if IBM
caved in and bought out SCO for several hundred million dollars, then Yarro
would profit greatly.

That being the case, maybe Yarro wasn't fooled by McBride, but knew from the
beginning that it was a scam. In fact, maybe he came up with the idea in the
first place.

There is something else here, too. I had always assumed that Yarro was a
successful executive running a successful company, and so he had no need to run
a scam against IBM. But the complaint says that Canopy had actually been losing
money since 1998, except for the money from the DR-DOS suit. And of course, what
we learn from the suit, assuming its claims are correct, is that Yarro is a
crook. With all that in mind, it seems quite possible he is the sort of person
who would engage in a scam against IBM.

One more point. Suppose that Yarro knew that SCO's suit was a scam when he
approved it. In that case he would have put Canopy in danger of being sued by
IBM, and so Canopy could sue him over that. However, Canopy can't include this
in their complaint, because to do so would be to admit Canopy had done something
wrong in approving the lawsuit. It would only be after IBM sued Canopy that
Canopy could then sue Yarro over it.

Lots of complications. I sure wish I could see what IBM is coming up with in

[ Reply to This | # ]

Myths About Samba by Andrew Tridgell
Authored by: Anonymous on Sunday, February 06 2005 @ 06:23 PM EST
cool.. I didn't know most of that.. thanks..

hey perhaps you could make a "Open Source Myth Busting" section??

[ Reply to This | # ]

The real question is...
Authored by: capn_buzzcut on Sunday, February 06 2005 @ 09:09 PM EST
The question of the Samba development methods being
"reverse engineering" or not is really just a question of
semantics. Frankly, I don't care if you call it "reverse
engineering", "manna from the Gods", or "purple rain".

The important question here is whether or not the
development methods used could open up an avenue for
future legal attacks. Yes or no?

[ Reply to This | # ]

Myths About Samba by Andrew Tridgell
Authored by: John Hasler on Sunday, February 06 2005 @ 09:14 PM EST
Thank you for posting this. I have always ignored Samba because I was led to believe that it existed only to support Microsoft OS's of which I have none. I will now take a second look. Perhaps the text at What Is Samba could be revised so as to lessen the impression that Samba is solely a Microsoft compatibility package?

[ Reply to This | # ]

    Well, I'd like to say one small thing here...
    Authored by: Anonymous on Sunday, February 06 2005 @ 09:24 PM EST
    Thank you Andrew for all the hard work you and the Samba team have done on a
    great piece of software--regardless of the semantics and nuances of the meaning
    of words.


    [ Reply to This | # ]

    • Seconded - Authored by: Anonymous on Sunday, February 06 2005 @ 10:37 PM EST
      • thirded ! - Authored by: Anonymous on Monday, February 07 2005 @ 08:54 AM EST
    Myths About Samba by Andrew Tridgell
    Authored by: Anonymous on Monday, February 07 2005 @ 12:14 AM EST
    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.

    Pitty whatever they choose to call it the courts have ruled its a violation
    against the DMCA. See Blizzard vs Bnetd.

    [ Reply to This | # ]

    time travel
    Authored by: unsubtle on Monday, February 07 2005 @ 01:32 AM EST
    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.

    or bill gates invented time travel and dr tridgell stole the idea!

    we know that time travel is possible for short distances. this is the only sensible explanation for why the USPTO ignores prior art unless it predates the filing of a patent by at least a year. clearly the USPTO, whose understanding of technology is without peer, believe that the furthest a potential patent fraudster could travel back in time is:

    1 year
    + [the time between when a patent is filed and when it's publically available] +
    [the time required to create the fake "prior art"]
    in a cursory search of the USPTO's website, i couldn't find a patent on time travel. but of course some inventors (such as benjamin franklin) choose not to patent their inventions (thus proving that they are communists).

    [ Reply to This | # ]

    French Cafe vs Look and Feel?
    Authored by: Anonymous on Monday, February 07 2005 @ 01:00 PM EST
    Doesn't the French Cafe method have some relationship to the old "Look and
    Feel" issue that Apple sued a few folks over a decade or so ago? Aren't
    they both "emulating the interface" in effect? I thought Apple lost
    that one not because "Look and Feel" wasn't potentially a protectable
    characteristic, but because they weren't able to show proper ownership of their
    own "Look and Feel" given the Xerox Parc windowing systems, etc.. But
    I may be misremembering this case, it was some time ago...

    [ Reply to This | # ]

    Myths About Samba by Andrew Tridgell
    Authored by: WildCode on Monday, February 07 2005 @ 04:52 PM EST
    its ok to be paranoid where your data and microsoft is concerned. A few years
    ago they stated they they own any data going through their servers, reguardless
    of its source or destination. Whether it be a letter to your mum, or a program
    you were developing for a company, if for some reason it went through a MS
    server, they could claim the rights to it.

    [ Reply to This | # ]

    Groklaw © Copyright 2003-2013 Pamela Jones.
    All trademarks and copyrights on this page are owned by their respective owners.
    Comments are owned by the individual posters.

    PJ's articles are licensed under a Creative Commons License. ( Details )