Question for those developers that do not send source code. We have a
subset of our product that we do not want to sent the source code with the
product (i.e. security code etc.).

We have access to D3 7.21 on NT. The question is how do we get our product
on other versions of D3 - both on NT and Linux? The majority of the code we
will send source and just compile it. However, for that small subset, we
only want to send the object code.

Any suggestions?

At compile time, the object code exists in the dict of the file where the
source code is. If you send only the dict portion of the file instead of the
data portion, you should have no problems.

Albert

"Eugene Perry" <eperry1977novirus (AT) earthlink (DOT) net> wrote

The question is.....is object code generated on D3/NT compatible to
D3/Linux. And what about versions - we have 7.21 but is it compatible to
7.14 or 7.3 etc.

Eugene

"alauts" <albert_leland (AT) yahoo (DOT) com> wrote

Oh... In order to get the most complete answer, you'll have to give us more
specifics (i.e. source code). However, generally, source should be compiled
in the operating system that it's expected to run on. As far as
compatability between patch levels, or release levels, it all depends on
your source especially if you call Pick related programs or O/S executables.

Good luck on this one!

Albert

"Eugene Perry" <eperry1977novirus (AT) earthlink (DOT) net> wrote

The code is very generic - no flashing, no calling c routines etc.

Eugene

"alauts" <albert_leland (AT) yahoo (DOT) com> wrote

The problem is that we do not have access to many versions of D3 - currently
all we have is 7.21 for NT. It becomes difficult to compile the code on all
the different versions out there.

I do agree that generating the code on the version that it will run on is
the optimum solution.

Eugene

"alauts" <albert_leland (AT) yahoo (DOT) com> wrote

Provided you don't use the CRT statement you are in business .... if
you use CRT, you would want to compile your code on a 7.2.0 release
(or earlier), which IS forwards & backwards compatible

Just do a T-DUMP DICT <yourfilenamehere> on the source machine & you
can do a T-LOAD DICT <yourfilenamehere> (OR on the receiving end

HTH


"Eugene Perry" <eperry1977novirus (AT) earthlink (DOT) net> wrote

Ross Ferris wrote:
That has me curious! What would change about the CRT statement that
much? Seems like a pretty basic command.

Art

Another way around it is to write a proc which is the first thing T-
DUMPed and the first thing T-LOADed. The user at the other end must run
the proc to T-LOAD the rest of the programs. Then you can send the
source and have your proc compile it and then delete it.


--
Posted via http://dbforums.com

So what is to stop someone from just taking a look at the proc and manually
doing a t-fwd and getting the source?

It would certainly be nice if it was that simple - I would love it.

Eugene

"rockingred" <member35589 (AT) dbforums (DOT) com> wrote