Bob Blick wrote:

> Matt Pobursky wrote:
>
> >
> > I've found that to be true with pretty much every tool set we use here.
> > It's been our policy to archive the tool set used to create the production
> > code at every release. It's the only way we can guarantee that we can re-
> > create the code at a later date. We also put a note of which development
> > tools and version were used to create the code in each header file for each
> > module in a software project.
>
> Here's a place where I'll get on my soapbox. Imagine for a moment if
> your toolset requires a hardware dongle, key disk, or remote activation.
> Can make it kind of difficult in some scenarios. I tried to explain that
> recently to HiTech but they had themselves convinced that they weren't
> going to lose any customers other than me.

As a software tools developer we have thought about both of these issues a
lot.

1) Archived compilers need to have a reasonable probability of running
    when they are reloaded on systems often many years later. This means
    implementation rules for the tools originally must be conservative without
    any version specific OS requirements.

2) Protection is basically inconvenient all round. Most protection schemes
    don't achieve very well and it is essential to be able to wake up and
    old project and initially use  the original tools to validate that the
    archived sources and builds will still create the expected application
    code. Most protection schemes hurt most the very customers
    that tool companies want to have.

    Lots of companies get obsessed with protection. Most customers
    just want to get their development projects done and when needed
    get answers to their questions and timely response to tools issues.

    We decided against protection schemes a long time ago having
    decided it was counter productive.

w..


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist