🚀 go-pugleaf

In article <388F18CC.7834C2C0@wins.uva.nl>,
  Peter Vreman <pfvreman@wins.uva.nl> wrote:
> Robert AH Prins wrote:
>>
>> In article <260120001040598125%Jonas.Maebe@rug.ac.SPAM.ME.NOT.be>,
>>   Jonas Maebe <Jonas.Maebe@rug.ac.SPAM.ME.NOT.be> wrote:
>>> In article <260120001029588374%Jonas.Maebe@rug.ac.SPAM.ME.NOT.be>,
>>> Jonas Maebe <Jonas.Maebe@rug.ac.SPAM.ME.NOT.be> wrote:
>>>
>>>>> Note to the makers of (non-)commercial Pascal compilers
>>>>>(FreePascal/GNU Pascal & Virtual Pascal/TMT Pascal): Consider
>>>>>doing what IBM has done for years with its MF OSes, add user
>>>>>exits to your RTLs, an indirect far call, (defaulting to a far
>>>>>ret,) would be ever so useful, not only for debugging purposes,
>>>>>but also for profiling! (Consider making it available in a separate
>>>>>debugging/profiling RTL)
>>>>
>>>> In FPC (in Delphi, objfpc and FPC mode, but not in TP mode I
>>>> think), you can already do this using a "finalization" section
>>>> (this was first introduced in Delphi afaik).
>>>
>>> Hmm, seems I misread you post a bit at first :) Now that I reread
>>> it, I don't really see the difference between the standard exitproc
>>> mechanism and what you ask.
>>
>> I'm suprised that you don't, because are two very different phyla!
>>
>> Real operating systems (and many other MF tools) have so-called
>> user-exits, ie in Pascal terms the code would look like:
>>
>> ..
>> ..
>> call exit_xyz
>> ..
>> ..
>>
>> where the supplied exit_xyz would be no more than:
>>
>> procedure exit_xyz(params....)
>> begin
>> end;
>
> You can completly take over the heapmanager and write your own
> manager.

Completely taking over is something different, user-exits are mainly
provided to do small amounts of processing, in case of the heapmanager,
it could be something as simple as just writing out the address of the
caller and the amount of heap requested.

> We provide by default already a heaptrc unit which does a lot of
> checking on heap allocation/freeing. With go32v2 it's even possible to
> have checks for pointers.

I'll have a look at it.

>> However, the end user would be able to create his own exit_xyz and
>> use it instead of the manufacturer supplied one. Obvious examples are
>> the numerous Exx exits in mainframe SORT programs, which allow you to
>> pre- or post-process the incoming records - think Y2K!
>
> But then the end user should know a lot of the internals or the RTL.
> Most ppl are not interrested how the RTL internal work.

No! No! No! (I'm beginning to sound Osmo-ish, bad sign) See the example
I gave above.

>> In FPC they would be quite easy to implement, in TP/BP only a dirty
>> implementation is possible, unless you want to break SYSTEM.TPU. (Of
>> course, if FPC also uses some kind of CRC to detect changes to the
>> interface of a unit, the dirty implementation is also the only
>> viable one)
>
> What do the unit files have to do with this feature?

I've got the source of both the TP6 & BP7 RTLs, so I would easily add a

"call far [get_exit]" and
"call far [free_exit]"

directly after the "NewPtr" and "DisposePtr" RTL routines. The problem
is that I cannot put

"var get_exit, free_exit: pointer;"

in the interface of "SYSTEM.PAS", as that would break every other unit
using SYSTEM.TPU, which would leave me with no other choice than to put
these variables somewhere in the code, and access them by obtaining the
entry point of a known routine in the RTL, using a technique similar to
the one Andy user in his HEAPCHK unit in SWAG.

Robert
--
Robert AH Prins
prinsra@willis.com


Sent via Deja.com http://www.deja.com/
Before you buy.