Compilation strategy

Adam Wilson flyboynw at gmail.com
Mon Dec 17 00:01:15 PST 2012


On Sun, 16 Dec 2012 23:08:49 -0800, Jonathan M Davis <jmdavisProg at gmx.com>  
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.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/


More information about the Digitalmars-d mailing list