Hide some source in Dolphin

Hi,

Which is the way to hide source code in Dolphin ?

I have my system, and may be the people that use my application wants to buy
the code source.
(Of course if it the case they will need to buy a Dolphin and a OmniBase
licence).

I will not sale all myEnvironment code, only the Business Model. So, I want
to hide some Package source.

Which is the best way to do it ?

Regards Bruno

Bruno,

> Which is the way to hide source code in Dolphin ?
>
> I have my system, and may be the people that use my application wants to
buy
> the code source.
> (Of course if it the case they will need to buy a Dolphin and a OmniBase
> licence).
>
> I will not sale all myEnvironment code, only the Business Model. So, I
want
> to hide some Package source.
>
> Which is the best way to do it ?

Have you considered binary packages?  OA made some mention of possibly
removing the WDK in the next release, but I don't _think_ that would remove
the .pak mechanism - wouldn't hurt to check first though.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bruno, Bill,
remove
> the .pak mechanism - wouldn't hurt to check first though.

It is likely that the binary package mechanism will remain in D6.

Unfortunately, the standard Dolpin package system is a source code transfer
mechanism. This will make it rather difficult to use in a secure fashion to
transfer classes to a user and then to end up with the source code hidden.

Maybe binary packages will do what you want. Be aware though that even then
it is fairly easy to write a bytecode disassembler that can pretty much
recreate Smalltalk source from just the compiled methods (although the
parameter names/temporary names/comments will of course be lost). So
anything that you come up with isn't going to be *that* secure.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

"Bruno" <[hidden email]> wrote in message
news:b9bpre$hm0ka$[hidden email]...
> Which is the way to hide source code in Dolphin ?
>
> I have my system, and may be the people that use my application wants to
buy
> the code source.
> (Of course if it the case they will need to buy a Dolphin and a OmniBase
> licence).
>
> I will not sale all myEnvironment code, only the Business Model. So, I
want
> to hide some Package source.

Even if the binary package feature is removed from Dolphin I imagine that
you could put together you own way of importing byte code.  As Andy says,
this can still be decompiled.  You also may have problems if the Dolphin
byte code format changes in some future version.

Another option might be "shrouded source".  I believe it is commonly used to
distribute *nix programs that may need to be compiled for different flavors.
Essentially the code is processed to mangle all the names, instance
variables, private methods, maybe even private classes.  Perhaps the
refactoring browser code to be used to script this.  I think you would only
want to encode methods used exclusively in your private class.  This
approach would make it difficult to understand the shrouded code, but so
long as you adhered to good naming rules (no exotic characters) the code is
likely to work in future versions of Dolphin.

Actually another option just occurred to me.  I believe we can write ActiveX
DLLs in Dolphin (However, I get the impression this is not easy).  You could
generate an ActiveX DLL from Dolphin with your private code, and let your
users access it from another Dolphin image with public code.  An additional
benefit might be that your users could use whatever language they are
comfortable with, though of course you can highly recommend Dolphin. ;)

Chris

Bruno wrote:

> I will not sale all myEnvironment code, only the Business Model. So,
> I want to hide some Package source.

I'm just curious, what is the value *to you* of hiding your "environment"
code ?

    -- chris

> I'm just curious, what is the value *to you* of hiding your "environment"
> code ?

I have made a lot of "Base Package" that I reuse in every project. For
example, interaction with OmniBase, a lot of Presenters facilities, etc.
Although there's some package that are not so important, but there's a core
that do not want to sale but i must put it in the image in order to system
work correctly.

Regards Bruno

PS: We want to share this package:
In this page there's a few package for download (the package description is
in Spanish) so:
http://www.walicxe.com/pages/descargas.php

WalicXe - Development Tools --> Includes:
* Code Generator.
* WalicXe Package Browser (can do drag and drop from aPackage to aFolder).
* Bug Report.

WalicXe - Printing --> Includes:
* Small interfase with Windows printing system.

WalicXe - Spooler --> Includes:
* Additional interfase to interact with installed Printers (you can add, and
remove Printers).

WalicXe - SDK Interprocess Communicatios --> Includes:
* MailslotClient and MailslotServer (check MSDN), etc (very small).

WalicXe - Widgets --> Includes:
* PushButton specialization, with this you can put Text and anImage inside a
Button (FlatTextImageButton).
* IconButton: you can specify anImage (#imageDown) when the button is idle
and anOtherImage when the button is pressed (#imageUp).

Bruno,
I think a good way to do that is that you give them a .pac with "their"
sources.
And besides you give them a "closed" .exe (+ .dll).
Your customer will have the code, the Dolphin VM and the Dolphin Base Image
if they want to change it.

Hope it helps

Best regards,

Osvaldo

"Andy Bower" <[hidden email]> wrote in message
news:3eba26da$[hidden email]...
> Bruno, Bill,
>
> > > Which is the way to hide source code in Dolphin ?
> > >
> > > I have my system, and may be the people that use my application wants
to
> > buy
> > > the code source.
> > > (Of course if it the case they will need to buy a Dolphin and a
OmniBase transfer
> mechanism. This will make it rather difficult to use in a secure fashion
to
> transfer classes to a user and then to end up with the source code hidden.
>
> Maybe binary packages will do what you want. Be aware though that even
then

Bruno wrote:

> > I'm just curious, what is the value *to you* of hiding your
> > "environment" code ?
>
> [...] but there's a core that do not want to sale [...]

Yes, that was my question.  What do *you* loose if you do provide the base
package too ?

I mean, for instance, is it that:

The base package is something you'd want to sell independently.  In which case
why not just sell it to them now ?

The base package is not something that you want to provide support for (except
as it's used in the commercial code).  In that case why not just say so in the
licensing ?  Maybe have the option of just deleting the source after the
package is loaded (it wouldn't prevent anyone *looking* at the source, but it'd
stop them using it *by mistake*, which is maybe all you'd need in this case).

The base package gives you considerable competetive advantage, so you don't
want to loose it.  In that case you do need some fairly heavyweight protection
(subject to Andy'd caveat about it being pretty easy to decompile bytecodes).
Perhaps OA would be willing to sell you a modified installer that includes your
base code in the installation, and uses their code-hiding technology to ensure
that no source was left in the resulting installed image.  (I imagine that'd
cost a fair bit -- but that's my point: you have to consider what the *actual*
benefit *to you* is of hiding the source).

And so on...

    -- chris

P.S. If *I* had this requirement, I think I'd most likely hack up a modified
form of the package save mechanism that saved methods as bytecodes (perhaps
STBing the CompiledMethod) instead of in source chunks.  Quite a bit of messing
around, though, so I'd need to know *why* it was worth going to all that bother
first.

    -- c

Hi,

> The base package is not something that you want to provide support for
(except
> as it's used in the commercial code).  In that case why not just say so in
the
> licensing ?

This is case. This is the best thing to do (put non comercial use in the
license).
I thought that may be there was an easy way to hide some source.
But ....
> (subject to Andy'd caveat about it being pretty easy to decompile
bytecodes).

Regards Bruno