linking high-mem enabled modules and high-mem disabled modules together

[KO Myung-Hun]

Hi/2.

When linking high-mem enabled modules and high-mem disabled modules together, high-mem is not enabled. For example, in case of high-mem enabled executable linked against high-mem disabled DLLs, high-mem is not enabled.

This is because __libc_HeapVote() does not set enmResult to enmHigh never once it is set to enmLow. Is this an intention or a bug ?

Anyway, this does not look correct. I think, the way to go is to enable high-mem by default even if -Zhigh-mem is not specified. kLIBC already includes os2safe.h by default.

[Yuri Dario]

This is intentional. If a dll is not highmem enabled, it is not safe to pass a highmem data pointer to it.

[KO Myung-Hun]

Then, it would be better to use _lmalloc for those dlls rather than to disable high-mem feature itself at all.

Anyway, making a high-mem feature default is needed sometime. How about ?

[dmik]

This not strictly belongs here but somewhat related. We've run in to an interesting case here when building PE/PEC from Odin. There we use -nostdlib which disables the standard C library (including things like __lmalloc). However, since os2safe.h is now included by default, this will always give unresolved exports if the program uses any of Dos calls for which we have wrappers. The only solution is to use -DNO_INCLUDE_SAFE_HIMEM_WRAPPERS in this case.

This raises the same question again (already discussed elsewhere): -Zhigh-mem, inclusion of os2safe.h and (now) the -nostdlib switch should somehow correlate. E.g. like this:

1. If -Zhigh-mem is given, os2safe.h is included by default, otherwise it is not.
2. If both -nostdlib and -Zhihg-mem are given, gcc aborts with an error about incompatible options.