[fpc-devel]FPC & DJGPP & GraphiX

Peter Beisel beisel at kbprueftechnik.frm.de
Thu May 23 16:56:09 CEST 2002


Hi Jonas, Hi Michael,
thank you very much, this was the right hint.

I could change my program with a little wrapper around the
library function call like this:

  procedure callFMallFree( i: longint);
  var
    old_ds_base, new_ds_base : dword;
  begin
  old_ds_base := get_segment_base_address( get_ds);   // go32
  set_segment_limit( get_ds, getDSlimit);             // go32
  fMallFree( i);                                      // that's the library
function
  new_ds_base := get_segment_base_address( get_ds);   // go32
  set_segment_limit( get_ds,-1);                      // just like Michael
does it in gxmem.pp
  adjustaddresses( old_ds_base, new_ds_base);         // function from
gxmem.pp
  end;

Now it works.

BUT:
1) it's a little different if the program starts in text mode and calls
the library function before it changes to graphics mode. But I think I can
handle this.

2) I found a bug in graphiX:
Try this little program:
  uses  graphix;
  var  p : pointer;
  begin
  // first we force the heap to grow
  getMem( p, 30000000);
  freemem(p, 30000000);
  // now we enter graphiX
  if InitGraphiX(ig_vesa,ig_lfb + ig_hwa) then
    begin
    if SetModeGraphiX( 800, 600, ig_col24) then
      begin
      // do some graphics
      graphix.initText;
      end;
    end;
  end.

This program crashes with runtime error 216 in line 6 when calling getmem!
Explanation:
When using the unit GraphiX the usage of gxmem is included. In the
initialisation part of the unit gxmem the heapError procedure is hooked
by NewHeapError.
In NewHeapError adjustAddresses is called. AdjustAddresses points to
AdjustAllAddresses (unit gxGo32v2). AdjustAllAddresses calls
CurGraphix.adjustAddresses.

BUT at this time curGraphix isn't initialized! Because curGraphix will
get initialized when entering GraphiX by calling initGraphix.

Regards Peter






Jonas Maebe schrieb:

> The reason is probably this: GraphiX changes the limit of the ds
> selector so that instead of just including the memory that has been
> allocated to the program, it also includes the linear frame buffer
> (which lies somewhere above 3.8GB most of the time). However, this limit
> is reset by the Dos extender every time the heap has to grow. Therefore,
> GraphiX hooks itself into the FPC heap manager so that it can adjust the
> limit of the ds selector everytime getmem is called. You can't do this
> for malloc etc from the C library, so you get a crash if malloc had to
> grow the heap.
>
> The only solution I see is to manually add calls to the function that
> adjusts the ds selectors limit. You should be able to find this function
> in the GraphiX sources by searching for "SetMemoryManager".
>
> Jonas
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel





More information about the fpc-devel mailing list