I have a different perspective, one aspect of which probably coincides with those on both 'sides' of the discussion put so far.
The MapBasic editor and compiler toolset is a disgrace, and has been for many years. Trey Patillo has my deepest thanks - for stopping me from going insane with a simple matter like constructing MapBasic dialogues - but his low-cost utilities (which I purchased, a few years back) are not perfect either. The cost of MapBasic is far too high, and adding the amount required for Trey's software I can't see why anyone would complain about Microsoft's pricing for .NET development tools. MapInfo Corp should offer MapBasic for free, and kick along Win32 MapInfo Pro for a few more years before it dies. The combination of price and poor usability of MapBasic has retarded development of modest quality tools and utilities for MapInfo Professional. Of course, such tools have appeared - eg, Encom's Discover has developed from a hotch-potch of stuff to a powerful must-have suite for geologists. And the MapInfo developer tools (MapX, etc - Win32) have been OK - though relatively highly-priced, in my opinion. [I leave aside ESRI pricing in this discussion - they'll kill their own market in a few years; we all know their products are professional but exorbitantly-priced. ] I know that few people here are interested in .NET, but the fact is one can develop entirely for free with Microsoft-only or Microsoft + open source tools, including excellent visual IDE. Now, with .NET 2.0 and the "Express" range, it's even better, even easier. All that's needed is the spatial extensions - and take heed: Microsoft MapPoint may one day be more than a toy GIS, or may be joined by a more capable sibling product. MapXtreme 2005 (v6.6 beta) seems to be developing well, and if I were a serious MBX coder I would be embracing that environment and convincing my customers to move into the 21st century. Meanwhile, my guess is that we have another 5 years of MBX and Win32 MapInfo sameness, enhanced by the same third-party people who have kept MI in our focus despite high upgrade prices and negligible enhancements over the years. It's a shame that someone didn't pick the MapBasic compiler to pieces and produce a better development environment, a few years ago, with an integrated "Visual" IDE similar to that which Visual Basic 3 and 4 had so many years ago. I know the language (MapBasic) is constrained by the innards of MapInfo, and cannot improve independently; and that the DDE / COM is as slow and as capable as custard. Perhaps Anssi and a group of MI-capable developers should work on an open source project to produce what I have just described. I don't want a DE-compiler - a modern development environment would be a preferable outcome, despite the arcane and antiquated language and interoperability cemented into the MapInfo core. If such a development environment had been around say 5 years ago, MI may have been shamed into producing a better add-in language model a few years earlier (I think the MapXtreme 2005 one is looking good), and products like MI 7.5+ about 5 years earlier (v8.5 looks like it has a few worthwhile features). Ian Thomas GeoSciSoft - Perth, Australia -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Erickson Sent: Wednesday, May 31, 2006 1:04 AM To: Uffe Kousgaard Cc: Mapinfo-L Subject: Re: [MI-L] MBX documentation I'd like to look at the argument from other side for a moment: Our company routinely provides MapBasic application development for commercial customers. In some instances, we've written a MapBasic utility to perform a simple task and then made that code available to the larger community (GreatCircleRoutes and the InetLibrary are a couple). When we provide application development for customers, we always stipulate if and how the client will receive the source code. Sometimes the source code remains the property of AnalyGIS, other times it becomes the property of the client - in either case, it's always clear who owns what. Now when it comes to decompiling source code - I personally, have never had to decompile anything. That's not to say I didn't spend hours and hours looking for the last place I put source code to fix a bug or add a feature to an existing MBX. The prospect of decompiling the MBX would have been quite useful at about 21:30 when I wasn't sure where I last put my "keys." Joe Bolian provides a useful service and he deserves due credit for the service he provides - I'm sure many a programmer will be forever indebted to him. I would argue that the capacity to recover my own source would have saved a couple of hours of my life not to mention a call to Joe the following day... I would personally like to believe that for the most part - people are basically good. There will always be a small minority who will seek to gain from the efforts of others - but for the most part we know who those people are and if asked to explain any part of their stolen source code they would probably have a hard time understanding why "they" did what they did and how all the pieces work together. The reality is that the capability to decompile MapBasic code has been around for a while. We've been lucky that the capability to decompile our applications has been in capable and trusted hands (i.e. Stopwatch Maps). I would argue that we've also been a bit naive as well. Maybe the best way to approach this would be to build a MapBasic obfuscator. This would be a really cool tool - although (with two versions of the source code lying around, I would hope you always remember which was the obfuscated code and which was the "real" code). In some ways having a MapBasic decompiler lying around signals a "coming of age" for the little language that could.... I just hope no one out there is decompiling my code... Ian Erickson AnalyGIS, LLC http:// www.analygis.com See AnalyGIS at work: http://65.39.85.13/google/ http://65.39.85.13/virtualearth/ Uffe Kousgaard wrote: > 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
