From:	H1357Sol AT huella DOT bitnet
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Date:	18 Jan 93 13:24:30 +0100

I have problems with GCC (Versions 2.1 and 2.2). Some of them are quite
misterious. I wrote a GUI system (with windows, 3D text & pixmap buttons, input
fields, list boxes, dialog boxes, etc), using GCC and the 16/256 color graphics
toolkit of Csaba Biegl (version : April 6. 1992). Then I wrote a program with
this GUI to process bitmap images recorded by a CCD camera and an image capture
board.  The module file that reads, displays and saves the bitmap images is
incorrectly translated on all systems I have tried except one. The program
segment in question:

In the header file BITMAP.H
 .........................................
typedef unsigned long		DWORD;
typedef unsigned int		WORD;
typedef unsigned char 		BYTE;
typedef int BOOL;

#ifdef __TURBOC__
	#define HUGE	 huge
#else
	#define HUGE
#endif

typedef struct {		/* size (MSDOS): 14 bytes	*/
	WORD	bfType;		/* Must be 'BM' 	*/
	DWORD	bfSize;		/* file size in DWORDs 	*/
	WORD	bfReserved1,    /* must be 0		*/
			bfReserved2;	/* must be 0		*/
	DWORD	bfOffBits;	/* offset from this structure to bits in map*/
	       } BITMAPFILEHEADER;
............................................
in BITMAP.C:

#include <stdio.h>
#ifdef __TURBOC__
	#include <alloc.h>
	#include <dos.h>
#else
	#include <std.h>
#endif

#include <io.h>
#include <stdlib.h>
#include <string.h>

#include <grx.h>
#include <mousex.h>

#include "satypes.h"
#include "colorset.h"
#include "bcinterf.h"
#include "frame.h"
#include "rect.h"
#include "gmouse.h"
#include "gevent.h"
#include "bitmap.h"
#include "bmpfile.h"
#include "msgbox.h"
#include "gcursor.h"

#ifdef __GNUC__
	#define farmalloc(s)	malloc(s)
	#define farfree(s)		free(s)
	#define HUGE
#else
	#define HUGE huge
#endif

static int nReduction = 1;
BITMAPFILEHEADER bmfLocal;
		....

/*======================================================================*/
BMP_WIN *ReadBmpFile(char *path)
/*----------------------------------------------------------------------*/
{
	BYTE *pBitmap;
	BYTE HUGE *pb;
	FILE *fI;
	int  f;
	unsigned w;
	long l;
	unsigned long lSize;
	BOOL isCancelled = FALSE;

	if(!path || !(fI = fopen(path,"rb")))
		return NULL;
	f = fileno(fI);
		/* its size under GCC would be 16 !*/
	read(f, &bmfLocal, 14);
	if(bmfLocal.bfType != 0x4d42)	/* i.e. 'BM' as integer on INTEL proc.*/
	{
		Error("'%s' nem bitmap file!", path);
		fclose(fI);
		return NULL;
	}
		....
	other program lines
}

The 'if(bmfLocal.bfType != 0x4d42) part of the program is translated to:

	813dfc194000424d0000	cmp [_bmfLocal], _SetFocus+202

i.e. the word value of 0x4d42 is taken as an address somwhere in the program.
Now the really interesting part: This part of the same program on my home PC
is translated right:

	66813dfc194000424d	cmp [_bmfLocal], 0x4d42

I have tried four PCs. Only my personal one could translate this part of the
file correctly! All the PCs I have tried were made in the far east, were using
MsDOS 5.0 and QEMM (version 6.0).

The configurations:
      PC1	25 Mhz i386 w i387, 8M, 210M IDE drive, Trident 8900 C
      PC2	40 Mhz i386 w. ?387, 4M, 80M IDE drive, ?? SVGA board
      PC3	33Mhz i486, 8M, 210M IDE drive, Trident 8900
      PC4	40 Mhz i386 w Cyrix 387, 16M, 340M IDE drive, Trident 8900

PC4 is my PC at home, PC2 is my friend's PC, while PC1 and 3 are from the
TU Budapest.

I have tried to cut all other part of the program to have a version that
exhibits the same problem, but I was not successful: If I does not include all
of the include files the translation problem is gone. I have tried to go around
this problem, but other parts of the files must also be mistranslated, because
the compiled code will not run properly.
It has nothing to do with the main memory available though. When I allocated
8.5M of main memory on my home PC, the compiler and (this part of) the program
just run fine.

An other (and I think connected) problem appears in this same module in the
function that saves a bitmap file.  The BITMAPFILEHEADER structure is written
to the disk on the wrong way. That part of the program:

	f = fopen(pbw->pszFileName,"wb");
	if(!f)
		return FALSE;
	bfh.bfType = 0x4d42;		/* 'BM'	in reversed order	*/
	bfh.bfReserved1 = bfh.bfReserved2 = 0;
		/*  14 is the size in bytes of the BITMAPFILEHEADER structure */
	bfh.bfOffBits = 14+sizeof(BITMAPINFOHEADER) +
								pbw->biInfoH.biClrUsed * sizeof(RGBQUAD);

	bfh.bfSize = bfh.bfOffBits + pbw->biInfoH.biSizeImage;

	fwrite(&bfh, 14, 1, f); 	/* erroneous with GCC		*/

This time the compiled program seems right (at least till the 'call _fwrite',
code), the buffer holding the structure is properly filled in with the byte
sequence:

	42 4D 36 5A 05 00 00 00 00 00 36 02 00 00
but the byte sequence written in the file is:
	42 4D FF 7F 36 5A 05 00 00 00 00 00 36 02

Neither of these problems is present when I use Borland C++ Ver 3.0 for the
translation. But I need GCC, because it produces protected mode code, and I
need to access all of the memory in my machine for 800 x 600 x 256 pictures,
a thing I cannot do with Borland C++.

I found some library functions to be just not right. Examples:
	int86x() (as correctly stated in the documentation) is the same as int86().
This is a serious problem, because int86x() is needed to execute those BIOS
or DOS interrupts that modifies the DS and ES registers.
	many useful interrupts are not suported at all, or does not work correctly.
E.g. int33 sometimes cannot get the mouse's state correctly
	The 'clock()' function in the library always returns 0 (so I had a problem
	to detect mouse double clicks)

I hope that somebody can help me with these problems. It would be very bad if
I could not use this fine compiler regularly, because I did find that other
(sometimes expensive) compilers that produces protected mode code just cannot
be used for graphical (non Ms Windows) applications with more then 16 colors
and not the base 640 x 480 pixels resolution.
									,   ,
								Andras Solyom

- Raw text -