-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, May 30, 2006 12:01 PM
To: [email protected]
Subject: MapInfo-L Digest, Vol 7, Issue 84
Send MapInfo-L mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MapInfo-L digest..."
Today's Topics:
1. Re: MBX documentation (Joutsiniemi Anssi)
2. Re: MBX documentation (Uffe Kousgaard)
3. Re: MBX documentation (Bill Thoen)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 May 2006 18:40:28 +0300
From: "Joutsiniemi Anssi" <[EMAIL PROTECTED]>
Subject: Re: [MI-L] MBX documentation
To: <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
Dear Bill,
I appreciate you comment very much, and it is exactly the thing I've
been
worried about all these years. Naturally encouragement for stealing is
not
the point in here...
The basic dilemma as I see it, is that MapBasic hasn't really been
developed
for several years. Trey Patillo has done some major job to provide some
alternatives, but it all seems to end up in compling the source code
itself.
The biggest problem rises, because I guess MBX file was in a first place
ment
to be decompilable! It is really surprising that the compilation process
only
looses the comments of the source code. As you know even the original
variable names, line numbers etc. remain in MBX's.
So once you give information for compiling you actually open the gate
other
way too. It's unavoidable drawback from this nearly looseless compiling.
I
see the future of MB as a useful tool for creating UI, but I guess there
is
still much more left.
Have to reconsider the pros and cons.
Take care,
Anssi
====================================================
Speaking as a MapBasic developer who has a considerable investment in
MapBasic applications and has clients who have invested even more to pay
me to build applications for them, I see no real advantage to releasing
information to the public about how to decompile an MBX. If you have
lost your source, and can prove the MBX is yours, Joe Bolian of
Stopwatch Maps has offered to decompile it for you for free. Outside of
recovering lost source code I see no good reason to empower any yahoo
with a tool to open up my code like a can of beans. It's not *that* easy
to create a decompiler, and I wouldn't want to see anyone who can't do
it just given the information to make it easy to steal my code and
compromise my clients' investments. By giving away the secrets you
soften up the environment for anyone to build a serious project based on
MapBasic and will only bring about its end that much quicker.
I think that MapBasic has at least a couple more years of useful
commercial life to it, and it is very likely that old MBX applications
will still run in the .NET environment for years beyond that. Of course,
if your goal is to destroy MapBasic as a tool to build commercial
applications, and force us all to move to more advanced languages and
techniques, then go for it. I would abandon MapBasic pretty fast as a
development tool if a decompiler was made available to the public. And
for those who can't move on to more complicated and expensive software
development solutions, you would simply be exposing them to all sorts of
abuse from theft of their ideas up to and including loading a virus into
thier MBXs.
What possible good would it do to make sorcerer's apprentices of anyone
whose heart has not been purifeid by the long quest to learn the lore
for themselves? ;-)
- Bill Thoen
------------------------------
Message: 2
Date: Tue, 30 May 2006 18:11:32 +0200
From: "Uffe Kousgaard" <[EMAIL PROTECTED]>
Subject: Re: [MI-L] MBX documentation
To: "Mapinfo-L" <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=response
I can only agree with Bill Thoen 100%.
It should be the author of an MBX's choice if the source code is
supplied or
not.
As developers we are already struggling with decompilers in the .NET
world,
which makes it harder to protect our intellectual property. We don't
need
another one accessible to everybody for mapbasic, even if my personal
investment in this area is much more limited.
Regards
Uffe Kousgaard
----- Original Message -----
From: "Bill Thoen" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, May 30, 2006 5:00 PM
Subject: Re: [MI-L] MBX documentation
> Speaking as a MapBasic developer who has a considerable investment in
> MapBasic applications and has clients who have invested even more to
pay
> me to build applications for them, I see no real advantage to
releasing
> information to the public about how to decompile an MBX. If you have
lost
> your source, and can prove the MBX is yours, Joe Bolian of Stopwatch
Maps
> has offered to decompile it for you for free. Outside of recovering
lost
> source code I see no good reason to empower any yahoo with a tool to
open
> up my code like a can of beans. It's not *that* easy to create a
> decompiler, and I wouldn't want to see anyone who can't do it just
given
> the information to make it easy to steal my code and compromise my
> clients' investments. By giving away the secrets you soften up the
> environment for anyone to build a serious project based on MapBasic
and
> will only bring about its end that much quicker.
>
> I think that MapBasic has at least a couple more years of useful
> commercial life to it, and it is very likely that old MBX applications
> will still run in the .NET environment for years beyond that. Of
course,
> if your goal is to destroy MapBasic as a tool to build commercial
> applications, and force us all to move to more advanced languages and
> techniques, then go for it. I would abandon MapBasic pretty fast as a
> development tool if a decompiler was made available to the public. And
for
> those who can't move on to more complicated and expensive software
> development solutions, you would simply be exposing them to all sorts
of
> abuse from theft of their ideas up to and including loading a virus
into
> thier MBXs.
>
> What possible good would it do to make sorcerer's apprentices of
anyone
> whose heart has not been purifeid by the long quest to learn the lore
for
> themselves? ;-)
>
> - Bill Thoen
>
> Joutsiniemi Anssi wrote:
>
>>Since the MB doesn't seem to be that chic any longer, I thought maybe
I
>>could
>>release my notes on MBX-file format as well. I know there is plenty of
>>delicate issues concerning the copyrights of compiled code and also
some
>>private money bound to it too. That is little strainge though, since
most
>>of
>>us know that it is rather easy to built a decompiler and at least
three of
>>them exists too (search List Archive if you like). Also some more
valuable
>>use can be thought for the documentation. For
>>example, currently the only compiler is the one that is provided by
the
>>Corp.
>>and it significantly affects for third party development. Does anybody
>>there
>>across the ocean know where they are heading to? I naturally don't
want to
>>make enemy with them. I'm looking neither profit nor new jobs (since I
got
>>plenty) for this and consider this just as an act for creating new
>>potential
>>for more advanced usage.
>> I guess the tweaking other peoples code isn't that big of a thread,
since
>> the
>>profound slowness of a MB code forces people truly developing software
to
>>use
>>DLL's and stuff anyway. People capable of programming it from
>>documentation
>>most likelly wouldn't find any usefull from the tiny snippets of code
>>available anyway. I have never made a dime by selling program code,
but I
>>know some of you have, so basicly I'm interested to hear points of
view
>>that
>>havent crossed my mind. If my initial idea of release is concidered
>>terribly
>>hostile or semi-criminal among you I'm happy to draw back this too.
>> Please, keep the discussion open in List, if possible.
>> Hard rock hallelujah
>>Anssi
>>
>>_______________________________________________
>>MapInfo-L mailing list
>>[email protected]
>>http://www.directionsmag.com/mailman/listinfo/mapinfo-l
>>
>>
>
> _______________________________________________
> MapInfo-L mailing list
> [email protected]
> http://www.directionsmag.com/mailman/listinfo/mapinfo-l
------------------------------
Message: 3
Date: Tue, 30 May 2006 10:38:20 -0600
From: Bill Thoen <[EMAIL PROTECTED]>
Subject: Re: [MI-L] MBX documentation
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Joutsiniemi Anssi wrote:
>The biggest problem rises, because I guess MBX file was in a first
place ment
>to be decompilable! It is really surprising that the compilation
process only
>looses the comments of the source code. As you know even the original
>variable names, line numbers etc. remain in MBX's.
>
>
No, it is the way it is because it's based on the ideas of Kemeny's
BASIC compiler which was simply a tokenizer that prepared code for being
interpreted on the fly. It's true that it doesn't create very secure
code and a serious hacker with some knowledge of compiler construction
can read it, but most people who use BASIC aren't able to read the
binary version. Personally, I think it's best not to give a monkey the
keys to the banana plantation, but a curious monkey would find such
knowledge interesting and enlightning.
>So once you give information for compiling you actually open the gate
other
>way too. It's unavoidable drawback from this nearly looseless
compiling. I
>see the future of MB as a useful tool for creating UI, but I guess
there is
>still much more left.
>
>Have to reconsider the pros and cons.
>
>
I guess I hadn't considered the possibility of being able to extend it
by revealing how it works. There might be some value in that.
But since the cat's out of the bag anyway I guess I should consider
building a code obfuscator to be used as a pre-compiling step, just to
make it harder for hackers to read the source code. That wouldn't be
hard to do because MapBasic doesn't need to be "neat" and human
readable. Simply changing all the function and variable names to things
like x001, x002, etc. would make it a pain to read and understand. And
once I saw the decompiler code, I could probably come up with other
annoying tricks to make it more difficult for the black hat hackers and
wannabes to understand what the code does.
- Bill
------------------------------
_______________________________________________
MapInfo-L mailing list
[email protected]
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
End of MapInfo-L Digest, Vol 7, Issue 84
****************************************
_______________________________________________
MapInfo-L mailing list
[email protected]
http://www.directionsmag.com/mailman/listinfo/mapinfo-l
