Shareware

As you might surmise from the topics, most of the sessions were about the business aspects of a productthe peripheral things that a good program needs to reach its market and compete successfully. These were the sessions that interest the business people and marketeers. There were only three technical sessions, each a round table discussion on the languages Delphi, C/C++, and Visual Basic. These three sessions were scheduled so that they did not conflict with each other. These were the sessions that interested the programmers.

Some of the companies are so small that both rolesbusiness and technicalare played by the same people. Shareware is a marketing concept that exploits various low-cost (to the developer) distribution mechanisms to bring a product to its market. The marketing model lets users try out the software and register it if they want to continue to use it. It's an old idea that goes way back to the origins of personal computers when a few small entrepreneurs used the model to achieve success, and it helped to enable the software cottage industry to thrive. The concept has evolved from those early beginnings such that a substantial support industry has grown up around it. There are now companies and products that exist specifically to support shareware developers with products for web development, registration, credit card processing, and the like. Several resellers were there. Resellers package and sell software that other companies produce and they were there vying for new products to add to their lines.

Shareware is not a category of software or a specific kind of application. It is, instead, a marketing concept. Programs marketed under the shareware label are otherwise indistinguishable from programs marketed any other way. The difference is in how they are marketed and distributed. Users typically download shareware applications from the Web or get them from CD-ROMs distributed by resellers. Shareware offers two advantages. Developers market and distribute their products inexpensively, and users test drive applications before they buy them. Shareware sometimes gets a bum rap in the media. The low cost of distribution enables a lot of junk software to find its way onto users' computers. Users can, of course, reject and refuse to register and pay for things that don't work. That's how it's supposed to work, but the simple fact that a lot of worthless software still resides on download sites casts a shadow on all shareware products and causes many in the establishment industry media to dismiss shareware products as being somehow substandard.

I was at the conference because my pal Donna Trujillo of Contact Plus Corp. was running the show and asked me to moderate the round-table discussion on C/C++ programming as it affects programmers today. The attendees were mostly programmers who have an interest in C and C++ and who, of course, write shareware applications. I gave my usual pitch about how programmers should be aware of the consequences of the new features of the language standard with respect to incompatibilities between libraries compiled with the old and new standard libraries and so on and then opened the floor for questions and comments.

Virtually all of the 30 or so programmers who joined my discussion group are developing for the Win32 platforms. Some of them are using Delphi or Visual Basic, but most are writing in C and C++ and using the Visual Studio suite for all their development tools. About half of them use C++ as an improved C and are only beginning to explore C++'s object-oriented extensions and the object-oriented programming model. Almost all the companies that attended the conference were represented in this group, so I must assume that the group accurately represented the shareware industry.

If this small conference is the representative sample that I take it for, no one is developing shareware applications in Java.

While on the subject of demographics, I must observe that all the programmers in my discussion group were white males with English as their principal language. That circumstance was a first for me in my many years of lecturing and moderating, and I do not know what conclusion, if any, it suggests about shareware programmers or entrepreneurs.

Platforms

Someone raised a question about the importance of cross-platform development and the extent to which Standard C++ enables that pursuit. There was concern that a typical application has to use so much platform-specific stuff that any emphasis on portability is an exercise in futility. I suggested that a well-designed C++ application uses encapsulation to isolate the problem domain from the user interface. Most of the programmers admitted that they understand the concept but don't judiciously apply it. We agreed that an application that is platform independent at the source-code level would probably use only the lowest common denominator of GUI features of all the platforms. It would be a shame to sacrifice some snazzy GUI features of Win32 in the name of platform independence only to have your Win32 version be the only one that sold. Nobody seemed to think that cross-platform compatibility was all that important. If their applications could succeed in the Win32 marketplace, they would be happy.

One company was porting its application from Win32 to Linux and asked what tools they might use. Someone asked them why they were doing that. They answered that they had read about all the other shareware companies who were doing the same thing. Yet no one else in the discussion was doing it. Someone offered a theory as to why there is the perception that a lot of Linux development is underway. He said that when his company gets a call asking if they are planning a Linux version, they say something like, "That's in our plans for the future," when they really have no such plans. They don't want to rule out the possibility with a flat denial and, being salespeople, want to keep the customer on the line. He guessed that most companies do the same thing. The result might be a growing impression that a lot of shareware companies are working on Linux versions when very few really are.

Open Source and Shareware

Last month in this column I addressed the Open Source model for software distribution and raised some questions about it. As I write this month's column, last month's has not yet been published, so I have no rush of e-mail that tells me about reactions to what I said. My interest in Open Source is still fired up, nonetheless. Inasmuch as shareware was the revolutionary software distribution and marketing model of a decade or so ago, I wondered how the shareware practitioners of today felt about Open Source, which is being touted by its proponents as the software distribution model of the future. Taking advantage of my captive audience of shareware programmers, I explained as objectively as I could the fundamentals of Open Source software and the arguments in its favor that I have read. I also expressed the concerns that I and others have about the concept. Then I asked the question, "What do you think about Open Source as a way to distribute your programs?" This group of software entrepreneurs were of a single mind about giving away their source code. They think that anyone who suggests it is nuts.

Shareware People

I met some of the luminaries of shareware at the conference. These are programmers who authored applications that I use or am familiar with. For example, I always assumed that Nico Mak Computing was a company name built from an acronym of some kind. Turns out Nico Mak is the programmer who wrote WinZip, and, as it turns out, a contributor to DDJ over the years.

I regularly use a program called "Cool Edit" from Syntrillium Software to process sound files. I met and talked with Bob Ellison, Syntrillium's president, about his product line. Besides Cool Edit's shareware version, Syntrillium markets a professional version and a few other neat programs.

I already mentioned Donna Trujillo, who was all over the place keeping the conference running smoothly. She and her husband Ed were there representing their product, Contact Plus, a business contact manager. Ed and I play in a big band together sometimes, and I use his program to keep track of musicians, what instruments they play, whether they can read music, what styles they play, and so on.

It's always helpful to put names and faces of people together with the software that they wrote and that I use. It softens my reaction when things don't work just the way I want them to, and it provides a mental target when I like something and want to say a silent "attaboy" to the programmer.

Boxer 99

I talked at length with David Hamel, who is the author of the Boxer 99 Text Editor, the new Windows version of his popular Boxer editor for MS-DOS. The original Boxer name was a knockoff on the widely used Brief editor that many programmers cut their DOS teeth on. Get it? Boxers? Briefs? Apparently no one did, because David changed his logo to a cartoon kangaroo wearing boxing gloves even though he says he hates the sport of boxing. Boxer is late coming to the Windows market, and David says that is on purpose. He wanted to be sure his product was reliable and comprehensive before releasing it. What a concept. He'd never make it in Redmond.

I looked at Boxer 99 briefly (pun intended) and wondered what would compel a programmer to use this editor rather than the one in a favorite IDE such as Visual Studio, C++Builder, or Delphi. Programmers can get emotional about their editors, at least they could in the old days when everything was done from the command line and in text mode and editors had personalities of their own. Today we have vanilla IDE editors that all look alike with nothing unique to endear them to programmers. Perhaps Boxer will arouse some of that dormant passion.

Since the Boxer moniker is a poke at Brief, it's probably fair to compare the two editors. It's convenient, too, because Brief was my editor of choice when I was text-mode bound. There was a Windows version of Brief after Borland acquired the product but it never enjoyed the success that the DOS version did.

Boxer is a solid, extensible programmer's editor that supports keyword color-coding, brace matching, and many other things that programmers want in an editor. Boxer's setup involves two diskettes, something that ought to be on a CD-ROM. Not that there's anything wrong with diskettes; it's just that when there are more than one, the potential to lose one of them in this abyss I call an office is much greater. Setup and the Boxer program itself have some really annoying sound effects that add nothing to the program. Fortunately, you can turn off the Boxer sounds from the Configure dialog.

Boxer's strength is in its syntax highlighting and the degree to which you can customize its views and its behavior. It comes with built-in knowledge of the keywords and syntax of many programming and document languages, and you can use its configuration features to add support for new syntaxes or change its behavior with ones it already supports.

You can use Boxer's User Tools feature to launch compilers, browsers, syntax checkers, and other programs, but the level of integration is somewhat primitive when compared to Brief, for example. There seems to be no way to intercept the message output from a compiler or other tool and associate it with a line of code in the editor window.

There are a few Help glitches. If you use the index and select the Templates keyword, for example, it displays the Macros topic. I wanted to find out about Templates and learned instead that macros are not supported. The help file says:

During the development of Boxer, we carefully studied how a comprehensive macro capability could be implemented. We found that the Windows environment poses unique complications in this area, and that a proper implementation of macrosas we envision themwould require a considerable development effort.

Well, what program of consequence doesn't involve a "considerable development effort?" That's not really a good excuse for omitting a feature. "We can't do it. It's too hard." Maybe they should say, "That's in our plans for the future (right after we finish the Linux port)."

By "a comprehensive macro capability" I assume they mean a macro processor with an underlying script language such as the one that Brief had and that the Visual Studio editor includes. That would indeed be a bit of an effort, although the VBA engine is available for developers to use. If I were going to add a macro scripting language to an editor, I would use the S interpreter that I developed about 10 years ago for a communications program project in this column. It implements an interpreted subset of the C language, and I designed it to be a scripting tool. But that's just me.

Brief and other editors include a keystroke macro feature in addition to their scripting macro tools. You record keystrokes in a macro and then simply play them back. It's a relatively unintelligent feature, but you can use it for repetitive tasks that can be done by keystrokes in the edit buffer. I implemented such a macro capability in an editor project in this column a few months back and found that the feature required very little effort to implement. My editor uses STL to record and play back event class objects with a vector container. Hamel told me that his program is written mostly in the C dialect of C++. Sometimes C++ turns what would otherwise be a "considerable development effort" into a walk in the park.

The Boxer Help file recommends that you use a complementary product named Macro Scheduler from MJT Net Ltd. to implement macros within Boxer. I haven't tried that option, but it might just fill the gap by providing one major feature that Boxer is missing. They suggest, too, that the Template feature provides a lot of what programmers want in macros. I haven't gotten that far. In fact, Boxer has so many features that I haven't even scratched the surface. I hope to get to know it a lot better.

DDJ