Hello,
I was told that High Memory is accessed by adding the OBJ_ANY flag to
memory allocation, like so:
DosAllocMem(&pMem,ulLen,...|OBJ_ANY)
How is this accomplished in GCC 3.3.5?
--
jimoe (at) sohnen-moe (dot) com
In <44F7D361.3000707 <at> sohnen-moe.com>, on 08/31/06
at 11:29 PM, James Moe <jimoe <at> sohnen-moe.com> said:
> I was told that High Memory is accessed by adding the OBJ_ANY flag to
>memory allocation, like so:
> DosAllocMem(&pMem,ulLen,...|OBJ_ANY)
> How is this accomplished in GCC 3.3.5?
I assume you mean how do I get the gcc runtime malloc() and new() to use
OBJ_ANY under the covers.
The place to start is the RTFRNs (i.e read the release notes which state)
o Enabled high memory support for LIBC. Two new options to GCC:
-Zhigh-mem and -Zhigh-low. If the program is to be enabled for
high memory use, specify -Zhigh-mem when linking.
I have to suspect that this is what you need, but I may need to pull a
copy of the libc sources to be sure.
BTW, I thought the plan was to port to OpenWatcom. Has this changed?
Regards,
Steven
--
--
----------------------------------------------------------------------
"Steven Levine" <steve53 <at> earthlink.net> MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4
(Continue reading)
Steven Levine wrote: > In <44F7D361.3000707 <at> sohnen-moe.com>, on 08/31/06 > at 11:29 PM, James Moe <jimoe <at> sohnen-moe.com> said: > > >> I was told that High Memory is accessed by adding the OBJ_ANY flag to >>memory allocation, like so: >> DosAllocMem(&pMem,ulLen,...|OBJ_ANY) > > >> How is this accomplished in GCC 3.3.5? > > > I assume you mean how do I get the gcc runtime malloc() and new() to use > OBJ_ANY under the covers. > > The place to start is the RTFRNs (i.e read the release notes which state) > > o Enabled high memory support for LIBC. Two new options to GCC: > -Zhigh-mem and -Zhigh-low. If the program is to be enabled for > high memory use, specify -Zhigh-mem when linking. > > I have to suspect that this is what you need, but I may need to pull a > copy of the libc sources to be sure. > > BTW, I thought the plan was to port to OpenWatcom. Has this changed? Nothing has change here, the above inforation is still valid. Feel free to do something similar for watcom. Actually, I've got a patch which make wlink use high memory for some purposes, but that's a very specific(Continue reading)
In <44F83F94.2060601 <at> anduin.net>, on 09/01/06 at 04:11 PM, "Knut St. Osmundsen" <bird <at> anduin.net> said: >> BTW, I thought the plan was to port to OpenWatcom. Has this changed? >Nothing has change here, the above inforation is still valid. I was not clear. I was asking James about an app he is working on. >Feel free >to do something similar for watcom. Actually, I've got a patch which >make wlink use high memory for some purposes, but that's a very specific >patch. A general way of doing it would be appreciated. I will make a note look at this. Currently, I'm working on some updates to the v1.6 wpp.exe. It has some issues that force some developers to continue to use the v1.2 version. Inlining is now working again. There have been some suggestions that the volatile logic has problems. Thanks, Steven -- -- ---------------------------------------------------------------------- "Steven Levine" <steve53 <at> earthlink.net> MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ----------------------------------------------------------------------
Steven Levine wrote: > > BTW, I thought the plan was to port to OpenWatcom. Has this changed? > It started that way. But there is a calling convention conflict with OpenLDAP. OpenLDAP was built with gcc 3.3.5 using the default calling. If I set OW to use the same, it sees the OpenLDAP lib entries but then it cannot find functions in its own libraries! I do not know of an easy way to fix it without building OpenLDAP with OW, which may not be possible. -- jimoe (at) sohnen-moe (dot) com
Steven Levine wrote: > >> I was told that High Memory is accessed by adding the OBJ_ANY flag to >>memory allocation, like so: >> DosAllocMem(&pMem,ulLen,...|OBJ_ANY) > >> How is this accomplished in GCC 3.3.5? > > I assume you mean how do I get the gcc runtime malloc() and new() to use > OBJ_ANY under the covers. > > The place to start is the RTFRNs (i.e read the release notes which state) > > o Enabled high memory support for LIBC. Two new options to GCC: > -Zhigh-mem and -Zhigh-low. If the program is to be enabled for > high memory use, specify -Zhigh-mem when linking. > Cool! That's easy. Thanks! Do you have any documentation, or where it can be found, the details what the High Memory bit is all about? -- jimoe (at) sohnen-moe (dot) com
In <44F894B5.2020007 <at> sohnen-moe.com>, on 09/01/06 at 01:14 PM, James Moe <jimoe <at> sohnen-moe.com> said: > It started that way. But there is a calling convention conflict with >OpenLDAP. OpenLDAP was built with gcc 3.3.5 using the default calling. If >I set OW to use the same, it sees the OpenLDAP lib entries but then it >cannot find functions in its own libraries! This is a typical calling convention issue caused by poorly constructed header files. Offhand, I'd suspect the cause is near line 137 of ldap_cdefs.h. > I do not know of an easy way to fix it without building OpenLDAP with >OW, which may not be possible. You can fix the LDAP headers, but building with gcc is OK too. Building with gcc will be slower, but I doubt there will be much of a noticable difference in the finished app's performance or size. Have fun, Steven -- -- ---------------------------------------------------------------------- "Steven Levine" <steve53 <at> earthlink.net> MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ----------------------------------------------------------------------
In <44F89524.3010702 <at> sohnen-moe.com>, on 09/01/06 at 01:16 PM, James Moe <jimoe <at> sohnen-moe.com> said: > Do you have any documentation, or where it can be found, the details >what the High Memory bit is all about? I don't have any links beyond what I've already given you. Once you understand how the original OS/2 arenas work, the upper arenas are pretty easy to understand. The OS/2 Debugging Handbook v#0.7a covers the original arena layout pretty well. Then imagine a second private and shared arena that lives above the lower arenas and below the system arena. Steven -- -- ---------------------------------------------------------------------- "Steven Levine" <steve53 <at> earthlink.net> MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ----------------------------------------------------------------------
Hi James, On Fri, 1 Sep 2006 20:14:45 UTC, James Moe <jimoe <at> sohnen-moe.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Steven Levine wrote: > > > > BTW, I thought the plan was to port to OpenWatcom. Has this changed? > > > It started that way. But there is a calling convention conflict with > OpenLDAP. OpenLDAP was built with gcc 3.3.5 using the default calling. If > I set OW to use the same, it sees the OpenLDAP lib entries but then it > cannot find functions in its own libraries! You mean someone _is_ actually trying to do something with OpenLDAP - I'd virtually given up on continuing to support it due to zero feedback on it...... -- -- Cheers, Paul.
On Fri, 1 Sep 2006 07:23:21 UTC, "Steven Levine" wrote: > The place to start is the RTFRNs (i.e read the release notes which state) > > o Enabled high memory support for LIBC. Two new options to GCC: > -Zhigh-mem and -Zhigh-low. If the program is to be enabled for > high memory use, specify -Zhigh-mem when linking. > > I have to suspect that this is what you need, but I may need to pull a > copy of the libc sources to be sure. Do I have to look into the sources or can someone tell me how this would affect execution of the resulting app on an older OS/2 version? -- -- Greetings, Peter.
RSS Feed4 | |
|---|---|
8 | |
3 | |
3 | |
9 | |
4 | |
1 | |
3 | |
2 | |
37 | |
39 | |
17 | |
41 | |
29 | |
28 | |
31 | |
79 | |
67 | |
9 | |
11 | |
11 | |
38 | |
9 | |
6 | |
14 | |
11 | |
2 | |
15 | |
8 | |
6 | |
20 | |
22 | |
58 | |
90 | |
72 | |
15 | |
13 | |
9 | |
20 | |
11 | |
33 | |
69 | |
82 | |
29 | |
4 | |
5 | |
3 | |
9 | |
67 | |
7 | |
28 | |
8 |
