Mike Chambers
Veteran Member
- Joined
- Sep 2, 2006
- Messages
- 2,621
Hi everyone, I haven't been around here much in quite a while! I see both a lot of familiar names still posting, and some new so I'm glad to see the forum is still alive and kicking.
I'm porting a piece of network software from *nix to real mode DOS using Open Watcom and the Watt32 lib. It's essentially working, but I'm wondering about memory allocation in the large model and how OW tries to malloc memory. My understanding is that in large, malloc() is equivalent to _fmalloc() and all pointers are far across the whole program. It should be able to use all memory available on the system, with the caveat that no single malloc() can give you more than 64 KB at once.
This software is a server program, and I'm running out of RAM after about 9 or 10 connections. I don't really know of a good way to dynamically monitor total RAM usage in this environment. There's the _memavl() function in Watcom, but it returns an unsigned 16-bit, so it obviously can't report back the entire amount of free memory in large. This number starts at about 29 KB, though as I get more connections, it drops down pretty quickly. The number doesn't change until several connections have already been made though.
I'm just not sure if it's actually using up all available RAM on the system before eating up memory from what is being reported by _memavl(). What 64 KB area is that reporting on? The near heap?
Is there a way to really see what's going on with RAM allocation? It's a fairly big program. The EXE is 400 KB, and I know Watt32 is hungry for TCP buffer memory so maybe I really am out of RAM already. Is it initially using what's available in the far heap, then digs into the near heap when that's exhausted? This may explain why _memavl() doesn't report any difference for the first several client connections.
I've been out of the retroprogramming hobby for a while. I'm feeling a little rusty. If I'm really out of RAM, maybe I can tinker with Watt32 to make it less memory hungry at the expense of performance. I could also have OW optimize for size instead of speed to possibly gain another 10-20 KB...
I'm porting a piece of network software from *nix to real mode DOS using Open Watcom and the Watt32 lib. It's essentially working, but I'm wondering about memory allocation in the large model and how OW tries to malloc memory. My understanding is that in large, malloc() is equivalent to _fmalloc() and all pointers are far across the whole program. It should be able to use all memory available on the system, with the caveat that no single malloc() can give you more than 64 KB at once.
This software is a server program, and I'm running out of RAM after about 9 or 10 connections. I don't really know of a good way to dynamically monitor total RAM usage in this environment. There's the _memavl() function in Watcom, but it returns an unsigned 16-bit, so it obviously can't report back the entire amount of free memory in large. This number starts at about 29 KB, though as I get more connections, it drops down pretty quickly. The number doesn't change until several connections have already been made though.
I'm just not sure if it's actually using up all available RAM on the system before eating up memory from what is being reported by _memavl(). What 64 KB area is that reporting on? The near heap?
Is there a way to really see what's going on with RAM allocation? It's a fairly big program. The EXE is 400 KB, and I know Watt32 is hungry for TCP buffer memory so maybe I really am out of RAM already. Is it initially using what's available in the far heap, then digs into the near heap when that's exhausted? This may explain why _memavl() doesn't report any difference for the first several client connections.
I've been out of the retroprogramming hobby for a while. I'm feeling a little rusty. If I'm really out of RAM, maybe I can tinker with Watt32 to make it less memory hungry at the expense of performance. I could also have OW optimize for size instead of speed to possibly gain another 10-20 KB...
Last edited: