Previous: 22 My least favourite bits
Next: 24 The eight elements of ClearWin+
In this section:
In the early days of personal computers an application could well be distributed on a single floppy disk with an installation batch file that would put the program and all its ancillary parts, including typical test data, into one or more subsidiary folders on a hard disk. If we go back further than that, it might even have been possible to run the program from the supplied floppy disk!
Nowadays, there is bound to be a lot more ancillary material to go with an application, and this may include not only the main compiled help file but other documentation and in the case of a program compiled with 32 bit FTN95, at the very least it will require a copy of SALFLIBC.DLL. In the case of 64-bit FTN95 it may require other dynamic link libraries, SALFLIBC.DLL and CLEARWIN64.DLL).
In order to get the effects that the application programmer has built into the program it may be necessary to install other fonts and to register various things with the main windows registry. To do all of this requires an installer application.
Users may be familiar with downloaded applications where first you download a .MSI file, and when that is executed, it makes other downloads and goes on to install everything. An alternative approach is to wrap everything up in a single .EXE file with the compressed (or zipped) versions of the application executable and its ancillaries. When that installation program is run it unzips itself, puts the various parts in the right locations, installs fonts and makes the registry entries, and on completion possibly even offers to run the program.
If you choose the .MSI route, then you will need to acquire the appropriate software to generate such files, but if you choose the self-unzipping executable, then you are following the same route as I follow. You may find commercial software, or freeware. I use some software called Inno Setup written and kindly distributed as freeware by Jordan Russell’s software organisation and which is to be found at this web address:< br/> https://jrsoftware.org/isinfo.php
To use this software, you create a script that contains instructions on what files are to be included and where they must unpack, and Inno Setup packs everything into a single executable file, which when run unpacks itself. You can also install fonts and other features, update the Registry and so on. One nice feature of the software is that you can personalise it with your own program’s bitmap.
You will be pleasantly surprised at how small the installation executable is, and in many cases, you could distribute your program via a fairly quick Internet download. The era of extremely cheap recordable CD media appears to be over (which is a pity) because most computers bought new are no longer equipped with CD or DVD drives. Removable USB media tend to have far more capacity than you really need and also, they are priced much more than a single CD. They are usually the wrong shape to slip into a wallet inside a user manual, although it is possible to purchase USB media that is the same size as a credit card and perhaps twice as thick. Such media can be printed with the appropriate branding.
Despite the prevalence of online help, many users prefer to have some sort of paper manual, and if installation of your software requires any special knowledge you will at least need a pamphlet because the online help will not be available until something is installed. There are many print shops that will produce booklets for you and provided they are not overlong, they are not particularly expensive even in comparatively short runs. You may even be able to bind a manual yourself using a ring binder, but Wire-O binding looks far more professional. Many of those print shops offer ‘perfect’ binding where the pages are glued into a cover, or for a higher price, books can be prepared where the papers are sewn into signatures.
The choice as to whether or not to produce a user manual must be yours, but purchasers of your software usually consider it to be a better deal if they do get a printed manual and some media rather than just a digital download.
In the early days of personal computers, manuals would be supplied in ring binders, typically in something like A5 paper size format, and sometimes the ring binders themselves were put into sleeves. This can be expensive for short runs. Personally, I think that perfect binding with a gloss cover is adequate, but Wire-O binding does allow the manual to lay flat. For small print runs the turnaround time may be only a day or so, and it probably isn’t going to be more than a week. Printing companies can be found on the Web. The unit cost is much higher for short runs, but that is offset by the benefits to cash flow and the fact that you don’t need to store boxes of unused manuals! It also helps the budget not to have long print runs if the user manual is developed and enhanced rapidly.
I use Azimuth Print in Bristol: https://www.azimuthprint.co.uk/
One of the significant advantages of Windows is that you simply do not need to bother about the installation of drivers for hardcopy devices such as printers. However, some of the real facts of life about printers may impact on your program. The most common printers in much of the world will imagine that you are going to use A4 sized paper, and you have probably designed your report formats around this paper size with comparatively small margins although do not forget that it is beneficial to have margins sufficient to allow the printout to be punched to be filed away in some form of a ring binder. Although it is useful to have a wider margin on the left than on the right if you are going to print single sided, and in fact you can organise yourself to have to say wider left margins on odd-numbered pages and wider right margins on even-numbered pages so that everything works if the user selects double sided printing. Even so my recommendation is to keep the margins on both side of the page the same.
If you expect your application to be run in the USA, or possibly Canada, their default paper size is US letter, and it is a good idea to make sure that whatever you print will also work at that paper size.
Another user setting for both laser printers and ink jet printers is the dots per inch (dpi) setting, and you should test out any graphics that you produce at a high-resolution dpi setting to make sure that all your lines are in fact thick enough to show.
Very occasionally, you will need to deal with larger than default paper sizes, depending on what your application actually does. An application of mine which plots maps does not work particularly well on A4 given the size and scale of typical surveys, and so expects A3 size paper (on which it works very well). However, if your application prints material formatted for A4 on an A3 printer, it turns out to be very wasteful of paper or alternatively of ink or toner if scaled to fit, and applications that occasionally require large paper sizes will probably run on a computer or network that has both A4 and A3 (or bigger) printers. You therefore need to program in your application that the user can select either the default printer (which will normally be the A4 page size printer) or to specify a different printer which has the larger format capability.
I have arranged prints on multiple pages to cover the area that is too big to fit on one A4 page, but if you do that you must have control over the scaling or you will end up printing many blank pages and pages with not very much detail on them.
Most computer users make do with a single screen whether they are using a desktop computer or a laptop and indeed a single screen is often perfectly satisfactory if it has a high enough resolution. However, it is very advisable to test your application on at least a dual monitor setup to see what happens if the user tries to extend your application across two screens. Alternatively, if the user moves your application to a secondary screen, you may find that your dialogs pop up on the primary screen and that can be annoying.
Another situation where the computer imagines it has multiple monitors is when it is connected to a projector. This is a situation that arises when someone uses the computer and a projector to train others in the use of your application. Windows can be configured so that the application runs the same on the computer monitor as it does on the projector, but it could also be configured so that the projector is an extension to the computer monitor. It is advisable to test your application in a case where a projector is connected to make sure that it functions perfectly because there is nothing so likely to cause your application to be criticised as a mysterious apparent malfunction when an otherwise contented user attempts to demonstrate it to other people. You will find that problems are particularly acute where the computer has a high DPI setting, or where the projector has a much lower resolution than the computer screen. There is nothing you can do at the installation stage to cater for such an issue or issues other than to have performed a significant testing regime yourself to make sure things work as you intend.
The appropriate checks as to the number of monitors connected, the resolution and mode of each are given by the call to the Windows functions available via MSDN and not through any ClearWin+ functions.
As a general rule, the first suitable icon in your RESOURCES section (or .SRC file) is used as the program icon if your program is placed on the desktop. The problem arises because it’s not just a matter of a desktop icon: the program icon appears in the Start menu, it may be different for different icon size or DPI settings, and there are icons for recognised datafiles – again, in several possible size settings.
If you are programming for yourself, then you do not need to worry at all about copy protecting your software and indeed, if you are programming like I have done on occasion simply to help students at my university that I have also not worried about whether my programs are copyable and freely distributed. Such programs can have the name of the organisation for which they are written hardcoded into the executable. On the other hand, if your programs have a commercial value and are distributed for a fee then you will be very interested in copy protecting them so that they cannot be distributed and used by unlicensed organisations.
You have to be very careful not to make the validation of the licence too obstructive, or you will simply alienate your users. It is not therefore a good idea to make the user input their codes every time they use the application. A good tactic is to provide a purchaser with a code which is used when the program is installed or alternatively run for the first time. If you link that code to the name of the purchaser or their organisation so that when the program runs and produces a report it will have the name on the output, then that is often sufficient to dissuade anyone from casual copying. It does, however, mean that the licence extends to the entirety of the organisation rather than to an individual computer or user.
Programs that communicate via the internet to see if they are licensed will not work if that connection is absent. The best advice is to make the process simple so as not to annoy honest users.
If you are dealing with a small number of users, it is possible to create custom versions of the software for each client organisation, for example by adding their name and address as a string which is linked into each build. This can get tedious if you have a big client base.
Apart from that advice, the issue of generating licence codes is a programming issue that has nothing to do with this book.
FORTRAN and the ART of Windows Programming, Copyright © Eddie Bromhead, 2023.