On Monday, 17 December 2012 at 08:02:12 UTC, Adam Wilson wrote:
On Sun, 16 Dec 2012 23:08:49 -0800, Jonathan M Davis
<[email protected]> wrote:
On Sunday, December 16, 2012 22:58:26 Walter Bright wrote:
On 12/16/2012 10:27 PM, Jonathan M Davis wrote:
> If the entire .d file is there in binary form, then I don't
> see why it
> wouldn't work. .di files fail because they strip out the
implementation.
> If a binary format were used,
It's all about what is in the file, not whether it is text or
binary.
The concept of .di files and their ilk is fundamentally broken
precisely
because they're trying to strip what's in the file. That's
what causes the
problems.
> then we should be able to get away with keeping the
> implementation there, because then it's obfuscated rather
> than for
sitting
> there for all to see, which is why corporations and the
> like insist on
> distributing only headers. Even with an object file, the
> best that
you get
> is obfuscation, because it can always be reverse
> engineered, so it
seems
> to me that what needs to be avoided is providing text. As
> long as we
use
> text, we're forced to cut out the implementation and end up
> crippling
any
> code that uses that module, since it can't inline it or use
> it in
CTFE.
> In binary format, it's obfuscated, so the entire
> implementation can be
> there, allowing inlining and CTFE to work.
This method of obfuscation simply will not hide things from
someone with
even modest technical ability, because *all* the source
information is
*necessarily* there in the file.
Object files are resistant to reverse engineering because
most of the
information is gone.
True, but they can stll be reverse engineered, and if the
problem is that
companies don't want 3rd parties looking at their code, then a
binary format
has obfuscated it and possibly solved that problem. Object
files do make it
harder, but they can still be reverse engineered, so it really
becomes a
question of what it takes to satisfy the folks who think that
not giving the
whole information in a .d or .cpp file somehow protects their
code (since it
doesn't really). And if a binary format can do that (as it
seems to in Java
land), then that seems like a far better solution, because
then we can leave
all of the information in there that inlining and CTFE need in
order to do
their jobs. With .di files, we'll never get that.
- Jonathan M Davis
Putting it all in binary and calling it good isn't really a
solution. Like it or not, the C/C++ header file provides what
larger corporations with IP to protect want. Difficult to
reverse (not impossible, but they know that and are willing to
accept it) with easy to access plaintext headers so the
legitimately licensed programmer can work with the product that
is rightfully his without stealing it. Not to mention that if
extracting binary was easy we'd all be doing it, and if we made
a tool to do it, then we'd be back to it being no different
than plaintext DI's which is I think what Walter was driving at.
With respect to those who hold one ideology above others,
trying to impose those ideals on another is a great way to
ensure animosity. What a business does with their code is
entirely up to them, and I would guess that even Richard
Stallman himself would take issue with trying to impose an
ideology on another person. What does that mean for D
practically? Using a close-to-home example, imagine if Remedy
decided that shipping their ENTIRE codebase in .DI files with
the product would cause them to give away some new rendering
trick that they came up with that nobody else had. And they
decided that this was unacceptable. What would they most likely
do? Rewrite the project in C++ and tell the D community to
kindly pound sand.
A license agreement is not enough to stop a thief. And once the
new trick makes it into the wild, as long as a competitor can
honestly say they had no idea how they got it (and they
probably really don't, as they saw it on a legitimate game
development website) the hands of the legal system are tied.
I know there are those here who think that D can thrive without
the support of the corporates. But realistically, they are the
ones who dictate the languages most coders use and therefore
learn. THAT's what makes the Remedy thing so important. By
showing other corps that D is safe, reliable, and understands
THEIR needs, they will begin investing in training there
people, and so on. This pushes more people to learn D. Is your
goal the proliferation of D or the proliferation of ideology?
And this idea that somehow because we lose CTFE, Inlining and
Auto support we should never allow DI's to be anything other
then full source distro's is borderline ridiculous. C++
programmers are under ZERO illusions that inlining was ever
going to work when using third party libraries, so the idea
that some things won't work is beyond routine. They won't even
notice, much less care. I'll put it to you this way, when I was
considering D for our projects, I asked what features I would
lose in redacted DI files. My entire response to the list was
"That's it? Sweet! This thing still beats C++ six ways from
Sunday."
Then I learned that the DI files weren't redacted. Now I have a
pull for it.
And as I referred in another thread, it is as not other languages
don't support this, except maybe for CTFE. But even then it is
mostly an implementation issue,
I think.
--
Paulo
