> > Environment changes sometimes you know! Thus, so does the RTL. There are
> > new means now.
>
> New means are good. I'm happy with this. But the removal of some
> "basics" which is not really enforced by the environment is what makes
> me unhappy.
If it can't be implemented sanely, it is not a basic.
Any of these functions (including *status *avail) basically have only
a few uses:
1) test and take decisions on memory use/availability
2) display user visible memory information
3) detect memory leaks.
4) internal use in e.g. unit tests to get a feel for the magnitude
(1) is seriously flawed, and should be avoided. Period. Not only the
multitasking problem, but also trashing because the program tries
to use more than the available physical memory. Either due to other
programs or because the total virtual size is reported by the OS.
(2) is dangerous since it confuses the user if available memory suddenly
increases while the program only requested another block from the
system.
(3) is a very primitive and somewhat incorrect (what if an automated type
happens to allocate a block of the same size somewhere as you
deallocate between memavails, it can really confuse. Better use
heaptrc)
(4) Is the only somewhat valid reason, but requires expert devel
interpretation to correct for problems mentioned in (1) and (2).
The fact is that the mem* routines are abundant in use for all these 4 types,
and we got really a lot of questions and bugreports for these fatally flawed
uses.
The Delphi eq Getheapstatus is not abused like that (since Delphi is windows
oriented and protected mode), so it was left in.
> >>I would hapily contribute the code for a better MemAvail/MaxAvail
> >>function if that's the problem.
This was all considered, and the end conclusion was that a satisfying
solution that lifts the problems 1..4 above is impossible. This, and to
avoid bugs creeping in while porting is one of the main reasons.
If this really bothers you a lot, add a memavail to your compability unit
and reroute it to getheapstatus or getfpcheapstatus (which are unfortunately
either wrongly, or not documented in 2.0.0)
> > Well, define these functions in your own compatibility unit then ?
>
> The -So autoload of such a unit as discussed with Florian would do the
> job so you don't have to change the good'ol code ;-).
IMHO these functions should not be brought back to the main distribution.
There were good reasons to remove them, and these still hold. In theory
they could be kept for go32v2 only use, but I don't like that either.
The few people that have TP compatible code and don't want to fix them
despite the warnings, should implement their own versions.
> P.S.: Please remember - the PC you are using is still around not because
> it's good but because it's compatible
PCS are not that compatible. I can not run my old games, I can not connect
my MFM disc, and a lot of old stuff doesn't work on new dos versions.
Only the usable subset has survived. FPC actually retains more than the
usable subset. (e.g. it retains dos functions that are superseeded by better
delphi functions). However the limit is at functions whose use is dangerous,
has the possibility of introducing bugs, and
> you can still run the first programs although most of the old games are
> unplayable on todays hardware ;-). Quite everybody seems to be happy with
> this "bug".
There is a lot that doesn't run. Actually, MSDOS 5.x fails to install on most
of todays computers. Compability is a good thing, but the 0.1% of it that is
relatively unused and even dangerous should be removed.
I can't lowlevel my IDE disc the same way from the BIOS as I did my MFM discs.
And that is a good thing, since that would ruin it, or it would fail for no
visible reason.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
