Holy cow, I wrote a book!
The reason why their feature sets are unrelated is that the two
programs are unrelated.
The find program came first.
As I noted in the article,
the find program dates back to 1982.
When it was ported to Windows NT,
Unicode support was added.
But nobody bothered to add any features to it.
It was intended to be a straight port of the old MS-DOS program.
one of my colleagues over on the MS-DOS team
missed having a grep program,
so he wrote his own.
Developers often write these little tools
to make their lives easier.
This was purely a side project,
not an official part of any version of MS-DOS or Windows.
When he moved to the Windows 95 team,
he brought his little box of tools with him,
and he ported some of them to Win32 in his spare time because,
well, that's what programmers do.
(This was back in the days when programmers
loved to program anything in their spare time.)
And that's where things stood for a long time.
The official find program just searched
for fixed strings, but could do so in Unicode.
Meanwhile, my colleague's little side project supported
regular expressions but not Unicode.
And then one day, the Windows 2000 Resource Kit team said,
"Hey, that's a pretty cool program you've got there.
Mind if we include it in the Resource Kit?"
"Sure, why not," my colleague replied.
"It's useful to me, maybe it'll be useful to somebody else."
in it went,
under the name qgrep.
Next, the Windows Resource Kit folks said,
"You know, it's kind of annoying that you have to go
install the Resource Kit just to get these useful tools.
Wouldn't it be great if we put the most useful ones in the core
I don't know what sort of cajoling was necessary,
but they convinced the Windows team to add a handful of
Resource Kit programs to Windows.
Along the way,
qgrep somehow changed its name to findstr.
(Other Resource Kit programs kept their names,
like where and diskraid.)
So there you have it.
You can think of the
find and findstr programs
as examples of parallel evolution.