Title: Members' Experiences

This contribution from Silas keeps this column limping along. I would love to share more of my experiences with you but time does not permit. What's your excuse?

Not everybody has heard of the Free Software Foundation, but, if you have a good Internet connection, then it is worth knowing about these people. GNU's website is http://www.gnu.org/ and contains a lot of information about their philosophy and so on (which there would be little point in duplicating here), but this is not the quickest way of finding ports to platforms other than Unix. Searching the Web (e.g. with http://www.metacrawler.com/) tends to be better for this, but, of course, make sure that what you end up with looks vaguely "official" and that you virus-check it.

There are two main implementations of a 32-bit Windows C and C++ compiler: Cygnus and Ming. Cygnus attempts to emulate a Unix environment, whereas Ming is a "minimalist" implementation with 32-bit Windows API headers, for compiling native Win32 applications. Unfortunately, it is difficult to install both without the two installations interfering with each other (you have to do a lot of environment variable setting). I installed Ming, because I could not get anything to work with Cygnus (I'm not that much a "Unix person").

I had various annoyances and things not working (like having to re-implement string.h, and g++ and streams not working), but I won't go into those because I later found that downloading a newer version fixed them. The only serious problem in the version I now have is a problem with file positions in text mode (fgetpos/fsetpos and ftell/fseek doesn't work properly) that I had to patch around in my code. Also I had an "ANSI C++ forbids implicit conversion from `void *' in assignment" warning whenever I tried to use stdargs.h (like Francis, I like my code to compile without warnings).

In case anyone wants to know, the problem with stdargs.h (which is a mistake that many programmers can make so I'll describe it now) is using 'typedef' as an alternative to '#define' without considering the differences. Somebody defined a __gnuc_va_list type and some macros to process it, then later on put a 'typedef __gnuc_va_list va_list' and assumed that the macros would still work without complaint. Some compilers (including gcc) will not treat these as synonymous without a cast. Rather than change the include file, for portability to other people's systems I patched around it in my code by writing:

#ifdef __GNUC_VA_LIST
#define va_list __gnuc_va_list
#endif
va_list argptr;
#ifdef __GNUC_VA_LIST
#undef va_list
#endif

and then writing '(va_list)argptr' when I subsequently passed it to vsprintf (that should give you a clue about what exactly I was trying to do). Well, I could submit a bug report to GNU, but they've probably spotted it by now anyway.

I could not get "make" to work, so I just did "g++ *.c++-osomething.exe" (I don't really like make utilities that force you to manually specify the header files for each object file anyway, because this may change with the program and one day I'd forget to update it). It seems that C++ files must have the extension c++, hence relying on long filenames and complicating the use of DOS editing facilities (like my syntax highlighter). It is also worth noting (when writing batch files etc) that the compiler will not delete an existing executable if it finds errors, so the existence of an executable does not imply that the last compilation actually worked unless the executable was explicitly deleted beforehand. I had set up a little batch file that involved redirecting the compiler's output, but it didn't work - the stuff refused to be re-directed (or paused). So, it was time to set a large buffer in a command prompt window, compile the program, and scroll up (I can't see well enough to have one of those tiny-print windows that shows you everything at once). This is the thing about gcc: When you go wrong, it is not always very helpful. It may say the error message, then scroll it off the screen with a few dozen others, and then perhaps crash with an access violation.

The compiler comes with a set of help files that describe the command-line use and so on. These made the annoying mistake of setting the text colour to black and leaving the background colour as it is (I have it set to black by default), so I either had to change colour scheme or copy all the text into Notepad in order to read it. Dear reader, please don't make the same mistake. If you can put up with that, though, there is good documentation, especially of the included tools (some of which are quite powerful).

I like GCC, now I have got used to its idiosyncrasies. I have written a few CGI programs in it, including an "access gateway" that sorts Web pages out for blind and partially sighted users (e.g. speech users have problems with multi-column text, too many frames have trouble with large fonts, and so on). The compilation time is fast (although there is no indication of progress unless errors and warnings are being printed) and it generates tight code. It is also fairly "standard" - now I am no longer restricted to being told what to do by Borland in 1991 (or whenever). I have tried using the Win32 API and it works (if you put "\mingw32\lib\libgdi32.a \mingw32\lib\libuser32.a" on the command line), and gcc also has a resource compiler, although you have to look in an unlikely place to find it ('windres' in hlp/binutils.hlp).

Using a DOS editor under 32-bit Windows was rather awkward (all that double scrolling and so on), and I needed a Windows editor suitable for source code that was reasonably better than Notepad. I found that the freeware Programmer's File Editor is quite good, the only thing it is seriously lacking being a syntax highlighter. Brace matching doesn't work too well if you don't put your braces as the last thing on a line - I sometimes put a comment after an open brace, and this confuses it. I also tried to install a port of emacs but had little success in getting anything more than basic editing functionality without so much as a large font, which is hardly worth 30Mb. I then found that PFE actually manages to capture gcc's output, which makes it definitely worth having.

The intriguing thing about PFE is that it displays international characters if you have set the correct font, although it is inconsistent - when I viewed one program with Japanese comments, it correctly interpreted katakana in EUC-JP encoding sometimes, and at other times treated it as some other encoding and substituted other characters. This is particularly noticeable if you select text or drag another window around on top of PFE (using NT's "show window contents when dragged" option), but it can be coped with by using the usual methods of dealing with screen corruption - scroll it off and on again or highlight it. I find no evidence that PFE was intended to display these encodings, and it is probably all a side effect of using certain Windows functions and sometimes not giving them all of the characters. If an unintentional feature is a bug, then the ability to display these characters is the best bug I've ever seen - why can't they all be like that?

Thanks Silas. I hope that a few more readers may be persuaded to throw in their experiences having read about yours.