Help System for Application Development

[Chris Summerfield]

Martin,

Thanks for the suggestion about -remote. I've been looking for documentation about what this might do, and I haven't found any. In fact, in wading through devedge.netscape.com and mozilla.org and a variety of other sites and online O'Reilly books, I haven't found anything about any switch options for Mozilla at all, except for -chrome. Oh yes, I also checked the hardcopy (printed) User's Guides for Netscape to no avail. I'm really surprised about the lack of documentation about Mozilla. I guess it's just supposed to be intuitively obvious, and if you're not savvy enough to intuit it, you shouldn't be using it.

[John Deutsch]

Chris,

I've had three further thoughts that speed up your entry into MOZILLA. These are not things which I've tried, but they might lead somewhere.

1. What about running MOZILLA as an installed image (I think that is the right term)? This could make it quicker to start up.

2. What about running MOZILLA as a service? I've never tried creating a service, and I'm not sure how that would work.

3. What about each user having MOZILLA running as a second session on their terminal? I don't know how you would tell it what file to look at. Maybe there is a way of doctoring its list of favourites or of recently visited addresses.

John

[Chris Summerfield]

John,

Good ideas, all. I imagine that having Mozilla be an installed image would be a step in the right direction, and I think that is about as far as VMS comes to having a service (other than running a detached process in hibernation or an event flag wait state). Overall, my take on this is that it is a decision for VMS Engineering to make, as they have provided MOZILLA.COM as the approved (supported?) method (so far) of starting Mozilla. I think they need to take a much more serious look at how to support a browser in VMS in a way that will minimize impact on startup performance and provide options that allow browser requests to be satisfied by either

a) opening a new browser window to satisfy the request (irrespective of whether another window is already open on the display); or

b) checking first to see if a browser window is already open on the display and, if so, using it to satisfy the request, if not, then opening a new window to satisfy the request.

My impression so far is that VMS Engineering has invested the minimum amount of effort possible to slap together something to run a browser on at least some of the systems that run VMS (ignoring VAX and ignoring the performance implications of the ways that browsers are used). I just think that history may prove this approach to be very short-sighted and unfortunate for the future of VMS.

The issue invites me to wonder what vision VMS Engineering has for the place of VMS in the world of operating systems anyway. What need to they expect it to satisfy in a world that is dominated by the Windows/Unix duo. Now that even Mac OS has become Unix, and the world of Unix variants is rapidly imploding to Linux. Porting to VMS to Itanium may be futile if no one elects to use it. And if it can't even run a browser...well...

[Martin P.J. Zinser]

Hello Chris,

try mozilla -help

which does give a link to a page
with information about -remote
(as I've written, that should be
usefull on Unix too, not only
OpenVMS)

<> superficial experimentation did show some problems. I guess this might be a process name issue. You might want to get in touch with
Colin Blake ( colin@theblakes.com) to sort them out.

Greetings, Martin

[John Deutsch]

Chris,

Maybe they have no vision beyond enabling existing VMS programs to run on newer hardware. I imagine that around the world there must be hundreds or thousands of VMS applications that cannot easily be moved to UNIX or WINDOWS, and that must keep going for several years to come.

I wrote a VMS application for a client in 1986 and they are still using it today, but with new features added in over the years. It has run on VMS since version 3, and is now run on an Alpha rather than a VAX. It was so central to their survival that when they were looking into which systems might put them out of business if they failed because of Y2K - it was in the first four that they listed.

They were seriously worried about the demise of DEC and the possible effect on the longevity of VMS and the machines. However (sadly for me) the nature of their products has changed in the last year or so, and they don't envisage needing the system for more than a few years.

John

[Chris Summerfield]

Martin,

Thanks for the reference. I checked out http://www.mozilla.org/unix/remote.html and now I understand a bit more about where the -remote option came from and where it might be going, along with some insight into the volunteer source efforts at mozilla.org. Not that I want to jump into the seamonkey source and start swimming around. That's well beyond the scope of my project. But I will certainly experiment with it and see what I can come up with.

John,

Yes, I too have been writing applications for VMS for a very long time. And some of them expire with time when customer needs change, or when the customers themselves expire. But other applications have the opporutnity to grow and change with the times. And those that do will grow and change only on those platforms that provide the facilities and support required to support the changing times. If VMS is going to assume a status quo posture, then I expect that it will die when its legacy applications die, surviving only for so long as HP (or whoever owns it next year) can find profit in supporting it.

I would like to think that if VMS can get its act together to provide reasonable support for a browser and some of the other basic functionality that the world expects from an operating system these days, then it might have a chance for life in the 21st century. Maybe HP can parlay the move to Itanium to make this happen, but time is running out as customers continue to look elsewhere, and it may be too little too late. Maybe. Maybe not. She loves me. She loves me not. She loves me...

[Chris Summerfield]

For those, if any, who might care to know, the -remote option does allow a couple of things that can be quite useful if you can afford to run a couple of commands via CLI and the MOZILLA.COM command procedure...

First, if you define a foreign command MOZILLA to run the MOZILLA.COM command procedure, such as

MOZILLA :== @SYS$COMMON:[MOZILLA]MOZILLA.COM

then you can use the -remote command option to determine if a browser is already running, as follows:

$ MOZILLA -remote "ping()"

If this command completes without error, then a browser is already running on the local display. If a browser is not running, the command will return error 2 and a text message.

Then if a browser is running already on the local display, you can cause it to display the contents of a file (instead of whatever it is already/currently displaying) by executing a command of the form

$ MOZILLA -remote "openFile(file:///sys$common:[somedirectory]myfilename.htm)"

and this can (might) execute in only a few seconds instead of a few minutes, as may be required if a browser is not already running on the local display.

Now if all of this could be encapsulated into a simple command that can be executed from within an application, and if we could get the initial startup time for the browser down to a couple of seconds instead of more than a minute, then we might really have something!

Our thanks to Martin for leading us down this road of discovery...

[Craig A Berry]

An alternative would be to distribute your help files in PDF format and use XPDF to read them on VMS. XPDF has a *much* lighter footprint than Mozilla; you could simply distribute the XPDF executable with your application. It may run on VAX as well, but I don't remember for sure.

I don't know if you mentioned what language you are using. If it's C, then you may find that system() or something from the exec() family are even easier than lib$spawn for invoking external programs in a subprocess. In particular, if you avail yourself of the VAXC$PATH logical name, then you don't have to hard code any paths when using exec().

[Martin P.J. Zinser]

If you follow Craigs advise
concerning Xpdf, just a few
hints from me:

1.) Wait a bit ;-) If everything
goes right the VMS ready version
of Xpdf 2.02 should appear at
http://www.decus.de:8080/www/vms/sw/xpdf.htmlx
some time this weekend.

2.) Make sure you build an executable with both T1lib and Freetype2, since this will give much better rendering.

Also for these two I hope to have the new versions up this weekend (5.0.0 and 2.1.4 resp) at the site above

[Chris Summerfield]

Thanks to Martin and Craig for the suggestions about PDF. A little background about our purpose...

We have an application that runs on Windows, Unix and VMS. Same functionality and considerable common code (written in C) on all platforms. The native GUI is Windows (of course) on Microsoft and Motif on Unix and VMS. Each dialog (panel or window) in the GUI has a "Help" button which, when clicked, causes a separate dialog to be displayed to show help for the dialog from which Help was invoked. The source for Help is, in fact, an HTML version of the User's Guide. We also provide an install on the user's system a PDF copy of the same User's Guide.

The plan has been to base the directly-linked help on HTML, and to provide the PDF files as a resource that users can view or print as a book at their discretion (provided they have a PDF reader installed). I suppose the reason for this has been the convenience of opening a window indexed to the proper page (anchor) in HTML, together with a navigation window on the left side of the display in Help (requires Java plug-in). And in Windows, of course, this is a "no-brainer" because all of the resources required to support this can be provided packaged in a single chm file that works like a charm in either Netscape or Explorer. In Unix and VMS we provide a Help directory that has about 100 separate HTML, gif and js files, with the Users Guide pdf in a separate doc directory.

Providing the pdf has sort of been an afterthought, like we give it to you and good luck with it if it's useful to you. We have had little expectation that it would be useful to Unix and VMS users, but if a decent pdf viewer is available that expectation may change. I'll certainly check it out!