21 Dec
2006
21 Dec
'06
5:09 p.m.
DEC bigots can skip this message safely. :-)
I've been working on a TCP/IP stack for my beloved PCjr. There are
already TCP/IP stacks that run on it, but that's not the point.
Borrowing a page from Tony's book, I decided to write my own so that I
could fix the inevitable bugs.
Anyway, I'm interested in reducing memory consumption. Any complex code
involves tradeoffs between function and performance, and I've been
careful, but one thing that is bothering me is the initialization code.
I've got a fair amount of code that reads environment variables, talks
to the packet driver, and sets up data structures. The nature of the
code is that it runs once, and then just sits there consuming memory.
Waaay back in history I was a Zbasic user - Zbasic was a fairly nice
BASIC dialect/compiler. Zbasic had overlay support, which I used
extensively. It wasn't sophisticated, but it did the job. It would be
perfect for this code - init everything that I need, and then overlay
the init code with the run code.
Now 20 years later I'm using Turbo C++ 3.0 for this project, and it has
overlay support but it has a more complicated memory manager that goes
along with it. I don't have a lot of 'gas' in the code, so going to the
VROOOM overlay manager just to overlay my init code is overkill, and
will probably require more memory. I was hoping Borland had a simpler
mechanism ...
Any ideas? The only one I can think of is kind of brute force ... have
two apps, one that inits everything and leaves the storage resident, and
another that refers to that resident storage. (I was hoping for
something simpler in the Borland runtime support.)
Mike
PS: I'm still looking for a late version of Zbasic .. I had 4.02 and I
know that 4.71 was released. I'd love to see what it evolved to, but
that's a different topic.
21 Dec
21 Dec
5:22 p.m.
It was thus said that the Great Michael B. Brutman once stated:
DEC bigots can skip this message safely. :-)
I've been working on a TCP/IP stack for my beloved PCjr. There are
already TCP/IP stacks that run on it, but that's not the point.
Borrowing a page from Tony's book, I decided to write my own so that I
could fix the inevitable bugs.
You're writing a TCP/IP stack for the PCjr in C++?
I'd say get away from C++ and find a C compiler. Smaller code, less
headaches.
Anyway, I'm interested in reducing memory
consumption. Any complex code
involves tradeoffs between function and performance, and I've been
careful, but one thing that is bothering me is the initialization code.
I've got a fair amount of code that reads environment variables, talks
to the packet driver, and sets up data structures. The nature of the
code is that it runs once, and then just sits there consuming memory.
How much code are we talking about here? IP itself isn't terribly complex
(UDP isn't much harder, although TCP is). The only thing I see being
required for setup is IP address, netmask, gateway (broadcast can be figured
out with the IP and netmask)---anything else (like DNS) can be added later I
would think.
Any ideas? The only one I can think of is kind of
brute force ... have
two apps, one that inits everything and leaves the storage resident, and
another that refers to that resident storage. (I was hoping for
something simpler in the Borland runtime support.)
Sorry, been too long since I last did MS-DOS programming (although if I
were to do it, I'd probably do it in Assembly, and reuse the init portion as
data space later on ... )
-spc (My second computer was a PCjr ... did quite a bit of development on
it, mostly assembler ... )
5:38 p.m.
In article <20061222012248.GB25389 at linus.groomlake.area51>,
Sean Conner <spc at conman.org> writes:
You're writing a TCP/IP stack for the PCjr in
C++?
I'd say get away from C++ and find a C compiler. Smaller code, less
headaches.
Only if you're a crappy C++ programmer.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
8:02 p.m.
New subject: OT Re: MS DOS overlay programming
On Thursday 21 December 2006 20:38, Richard wrote:
In article <20061222012248.GB25389 at
linus.groomlake.area51>,
Sean Conner <spc at conman.org> writes:
Most programmers I've dealt with are crappy programmers, let alone crappy
C++ programmers.
I won't say I'm great, but at least I know better than to do a lot of the
dumb-ass things I've seen in some OSS and commercial code I've worked
on.
Pat
--
Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
You're writing a TCP/IP stack for the PCjr
in C++?
I'd say get away from C++ and find a C compiler. Smaller code,
less headaches.
Only if you're a crappy C++ programmer.
5:48 p.m.
You're writing a TCP/IP stack for the PCjr in C++?
Don't be alarmed. I said C++. I'm not using polymorphism, inheritance,
etc. It looks very much like C code, except instead of structs I've got
classes and methods to operate on the classes. I'm not a purist about
C++ .. it's just a better C.
My test app is netcat. Right now, the EXE is is close to 54KB. That
includes all of the C runtime functions that I used and quite a bit of
tracing code that I can remove with a #define. I can keep piling in
code until I'm out of memory, but the fanatic in me says that the init
code should be removed because it only runs once. The init code includes:
-Reading env variables for IP addr, packet int #, netmask, gateway, MTU,
and a few options.
-Initializing the packet driver, getting the ethernet address, etc.
-Initializing ARP, UDP and TCP global data structures.
It's not a horrible amount of code; I just hate leaving it resident.
I'm using heap storage too, so my real storage requirements are a bit
higher. Still not enough to lose sleep over, but remember the fanatic part?
It's fairly easy to do a small IP implementation. UDP isn't bad either.
Doing a good TCP implementation (for both performance and required
function) has been a lot more difficult.
Mike
(If you need a Jr I can hook you up.)
7:11 p.m.
In article <017c01c7256b$98573950$6600a8c0 at HPLAPTOP>,
"Jay West" <jwest at classiccmp.org> writes:
The beauty and the ugliness of C++ is that it can mutate into almost
any kind of programming paradigm, depending on how much you want to
torture things like template classes and the preprocessor.
There's a reason its the "obfuscated C contest" and not the
'obfuscated Pascal contest'.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
I'm not a
purist about C++ .. it's just a better C.
Not all would agree :D 
7:39 p.m.
On 21 Dec 2006 at 20:11, Richard wrote:
The beauty and the ugliness of C++ is that it can
mutate into almost
any kind of programming paradigm, depending on how much you want to
torture things like template classes and the preprocessor.
I used to say the same thing about Ada.
Cheers,
Chuck
7:56 p.m.
On 21 Dec 2006 at 20:11, Richard wrote:
The beauty and the ugliness of C++ is that it can
mutate into almost
any kind of programming paradigm, depending on how much you want to
torture things like template classes and the preprocessor.
Come to think of it, I said pretty much the same thing about PL/I. :)
Cheers,
Chuck
8:57 p.m.
(If you need a Jr I can hook you up.)
How about cartridges/accessories? My jr is lonely.
I am a fairly blatant pro-Mac bigot, but the jr is a PC I like. It has
personality that didn't deserve the ham-handed market placement IBM
stuck it in.
--
--------------------------------- personal: http://www.armory.com/~spectre/ ---
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Time is what keeps everything from happening at once. ----------------------
6:33 p.m.
On 21 Dec 2006 at 19:09, Michael B. Brutman wrote:
Any ideas? The only one I can think of is kind of
brute force ... have
two apps, one that inits everything and leaves the storage resident, and
another that refers to that resident storage. (I was hoping for
something simpler in the Borland runtime support.)
That's the approach that I'd take--except I'd have the first one
write a temp file with all of the initialzed goodies and have the
second one read it in. It's dirty, quick and modular--and maybe
easier to debug.
I do know that not all C/C++ libraries are the same, nor are C/C++
compilers. Some generate lots of calls to the library, which can
bring in all sorts of unneeded garbage. I've written C programs with
their own startup code that run fine without any C library at all.
I don't know if that's even possible in C++, however.
Cheers,
Chuck
7:08 p.m.
Chuck Guzis wrote:
That's the approach that I'd take--except
I'd have the first one
write a temp file with all of the initialzed goodies and have the
second one read it in. It's dirty, quick and modular--and maybe
easier to debug.
Ah, now there is an idea. Quite a bit easier to implement than my idea
of trying to leave it resident in memory. Startup will be glacial ..
Of course maybe this isn't worth the effort ...
I do know that not all C/C++ libraries are the same,
nor are C/C++
compilers. Some generate lots of calls to the library, which can
bring in all sorts of unneeded garbage. I've written C programs with
their own startup code that run fine without any C library at all.
I don't know if that's even possible in C++, however.
No need to fear C++. It's just C with some extras.
If you choose to dink with stuff like templates, polymorphism, etc. you
get what you deserve. Otherwise, I look at it like just a better C. I
use new and malloc as it suits me, and never use iostreams .. good old
stdio works just fine.
This compiler (Borland Turbo C++ 3.0) generates a map file so that I can
see what I dragged in, and correct my code accordingly.
Mike
7:36 p.m.
In article <458B4C36.1020405 at brutman.com>,
"Michael B. Brutman" <mbbrutman-cctalk at brutman.com> writes:
If you choose to dink with stuff like templates,
polymorphism, etc. you
get what you deserve. Otherwise, I look at it like just a better C. I
use new and malloc as it suits me, and never use iostreams .. good old
stdio works just fine.
Templates don't have to lead to bloat. Templates are just the
preprocessor on steroids.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
7:55 p.m.
On 21 Dec 2006 at 21:08, Michael B. Brutman wrote:
No need to fear C++. It's just C with some
extras.
Not exactly--I've written plenty of C++ and find that the language
features are like chocolate--enough is wonderful, too much is
nauseating.
The uncertainty about libraries and such to me is the issue of memory
management--it's sort of hard to have constructors and destructors
without some sort of memory manager. OTOH, C can live just fine with
nothing more than a stack.
Here's where I draw my own (somewhat arbitrary) line--applications-
type user-mode code is great with C++, particularly if you have your
own class libraries all built up. If you have a memory leak or
dangling reference, it'll end up crashing your application, but the
system itself will likely keep chugging right along.
But if I'm going to write a device driver, TSR, or some other bit of
SYSTEM code in a HLL where memory utilization must be predicable and
well-behaved, I'll take C, thank you.
Just an old fogie speaking, so ignore if you wish.
Cheers,
Chuck
22 Dec
22 Dec
7:07 a.m.
Chuck Guzis wrote:
On 21 Dec 2006 at 21:08, Michael B. Brutman wrote:
Well, here you have a basic misunderstanding of how C++ works.
Constructors and destructors require a little more tracking, but it does
not require a memory manager. A constructor runs when an object is
created, and the destructor runs when it goes out of scope. If you are
working with objects on the stack then additional memory management is
not needed - the compiler generates extra code to call the destructor as
appropriate.
And that assumes you use destructors. My objects generally have
constructors for initialization, but never destructors. I revert back
to a more 'C' like technique of having a function that handles cleanup,
if it's needed. The best way to avoid forgetting to do cleanup is to
avoid putting yourself into a situation where cleanup is necessary. :-)
Destructors are one way to do that, good design is another.
No need to fear C++. It's just C with some
extras.
Not exactly--I've written plenty of C++ and find that the language
features are like chocolate--enough is wonderful, too much is
nauseating.
The uncertainty about libraries and such to me is the issue of memory
management--it's sort of hard to have constructors and destructors
without some sort of memory manager. OTOH, C can live just fine with
nothing more than a stack. Here's where I draw my own (somewhat arbitrary)
line--applications-
type user-mode code is great with C++, particularly if you have your
own class libraries all built up. If you have a memory leak or
dangling reference, it'll end up crashing your application, but the
system itself will likely keep chugging right along.
But if I'm going to write a device driver, TSR, or some other bit of
SYSTEM code in a HLL where memory utilization must be predicable and
well-behaved, I'll take C, thank you.
I don't understand again. I can write C code that is ugly too. C++ is
C with some extra syntactic sugar. If you use dumb functions in C,
you'll get bad system code too. This is just the stereotype of object
oriented languages being bloated/unpredictable, which is not necessarily
true.
I had a friend at Big Blue who told me he could do OO in RPG, or
assembler in C++. The choice was his.
Just an old fogie speaking, so ignore if you wish.
Cheers,
Chuck
7:23 a.m.
Rumor has it that Michael B. Brutman may have mentioned these words:
Chuck Guzis wrote:
I don't understand again. I can write C code that
is ugly too. C++ is C
with some extra syntactic sugar.
When I refer to C++ bloat, this is actually what I talk about - not the
'bloat' of the final code, that depends on the programmer, not the
language.[1] To me, it's hard enough to keep everything straight (and
readable) in C... and if C++ was *just basic classes* I could prolly wrap
my head around that enough to be comfortable. However, the polymorphism[2]
and operator overloading makes it (IMHO, of course) harder to discern what
others are doing with the code...
Now, I know just enough C to be dangerous, and hadn't touched C++ until a
few weeks ago, as I had to learn enough to tutor 2 college students for one
of their courses... ;-)
Altho now that I understand C++'s constructors & destructors a [very]
little better, I might be able to wrap my brain around Python's OO stuff a
little more easily... But at least OO isn't required there, either.
>Just an old fogie speaking, so ignore if you wish.
I seriously doubt I'm as old chronologically as you, but as they say:
You're only as old as you feel... so I must be pushin' about 80. ;-)
So I guess I'm an "old fogie Jr." ;-)
Prost, and Frueliche Weinachten!
Roger "Merch" Merchberger
[1] well, except PHP, but that's another thread; one that's best left alone...
[2] Now, if you get a "Wand of Polymorph" in Rogue, those are handy
rascals, indeed. ;-)
--
Roger "Merch" Merchberger | Anarchy doesn't scale well. -- Me
zmerch at 30below.com. |
SysAdmin, Iceberg Computers
7:38 a.m.
[...] and if C++ [were] *just basic classes* I could
prolly wrap my
head around that enough to be comfortable. However, the
polymorphism[2] and operator overloading makes it (IMHO, of course)
harder to discern what others are doing with the code...
"There is not now nor will there ever be a language in which it is the
least bit difficult to write bad code."
Yes, operator overloading and polymorphism can make for
difficult-to-read code if misused - but that's nothing new; so can a
lot of features of C. When used right, overloading and polymorphism
produce *more* readable code - though that's almost a tautology (since
improving readability is part of using them "right").
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
10:43 a.m.
On 22 Dec 2006 at 9:07, Michael B. Brutman wrote:
Well, here you have a basic misunderstanding of how
C++ works.
Constructors and destructors require a little more tracking, but it does
not require a memory manager. A constructor runs when an object is
created, and the destructor runs when it goes out of scope. If you are
working with objects on the stack then additional memory management is
not needed - the compiler generates extra code to call the destructor as
appropriate.
I know that--but it's the temptation to use new() and delete() that
can get you into trouble. If you never explicitly destroy an object,
then you're fine, as you've said--unless you were supposed to (e.g.
creating global instances and then forgetting to delete them).
Memory leaks can be some of the most frustrating things to debug--and
plenty of production code has been released with them. For whatever
reason, they seem to be more common in C++ than in C.
Heaven only knows, had I been more enlightened, I might have well
saved a bunch of deveopment time by devising classes and methods for
all of that nasty Windows NT kernel-mode stuff--or maybe not.
Debugging a device driver can be a pretty miserable job and the less
syntactic "noise" in the way, the better for me. But that's the way
my mind works.
OTOH, I've written application code in C++ and have been pleasantly
surpised at ease at which the application went together and the
resulting executable size.
That doesn't mean that I'm anti-OOP; that would be just silly. But I
can write a typedef for a struct that includes data, pointers and
pointers to functions perfectly well in C.
So, if I'm writing a little utility that requires two pieces--say, a
device driver and the application code that invokes it, I'l still
write the driver in C (or assembly, whichever is appropriate) and the
application in C++.
It's just the way I think.
Cheers,
Chuck
9:17 a.m.
Chuck Guzis wrote:
That's the approach that I'd take--except
I'd have the first one
write a temp file with all of the initialzed goodies and have the
second one read it in. It's dirty, quick and modular--and maybe
easier to debug.
Hey, pretty clever. Or, to save using disk as temp space, just have the
init program leave all that info in memory and pass the seg:ofs of the
struct to the 2nd portion of the code. If one chains to the other,
there's no fear of the data being overwritten.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
9:13 a.m.
Michael B. Brutman wrote:
Now 20 years later I'm using Turbo C++ 3.0 for this project, and it has
overlay support but it has a more complicated memory manager that goes
along with it. I don't have a lot of 'gas' in the code, so going to the
VROOOM overlay manager just to overlay my init code is overkill, and
will probably require more memory. I was hoping Borland had a simpler
mechanism ...
Turbo Pascal has a good overlay system, but it too is about 4K of code.
So if the amount of code size you're trying to save is the same size
or smaller than the overlay manager itself, it doesn't make sense to
overlay.
Unfortunately I can't think of any easy solutions at this point. I can
think of solutions, but not easy ones :)
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
28 Dec
28 Dec
3:56 p.m.
DEC bigots can skip this message safely. :-)
No they can't. ;) These techniques are of use on a lot of small memory
machines with rudimentary operating systems.
Sorry, have 5 minutes of spare time so I'm catching up on topics in
reverse order. Are you putting the TCP/IP stack in a TSR (and want to
reduce memory there). Or is it the application that you are trying to
reduce memory use in? If the application, is it a .com file or a
.exe?
I think an overlay manager is overkill. The general way I handled
such things (in the distant past, when I had time to do such fun
things) was....
If using a TSR or .COM file, place the initialization code after the
data section used by the initialization, feeling free to overwrite the
initialization code with data (.COM) or free the initialization code.
As long as you have your initialization variables in a static section
below the initialization code it's pretty easy.
It's a little bit more difficult in a .EXE file, since there is
(potentially) OS interaction with heap allocation. Methods I have used
are:
1) copying the initialization code to the top of the heap prior to
execution and storing the initialization data on top of the code that
was copied.
2) writing my own memory allocation code using a static variable as a
heap, and changing the link order to insure the initialization code
ends up above this variable.
3) manually modifying the heap pointers to "free" the initialization routines.
I'm sure there are other methods that I'm not thinking of, since this
was such a common problem.
Eric
4:34 p.m.
On 28 Dec 2006 at 15:56, Eric J Korpela wrote:
Sorry, have 5 minutes of spare time so I'm
catching up on topics in
reverse order. Are you putting the TCP/IP stack in a TSR (and want to
reduce memory there). Or is it the application that you are trying to
reduce memory use in? If the application, is it a .com file or a
.exe?
Back to my original suggestion. When I mentioned separating the
initialization and resident into two executables, I think most people
fell into the mental trap of "First you load the initializaion, do
it, then load the resident."
I think this is backward. Load the resident first, then execv() the
initialization, passing it pointers to whatever structures and data
are needed. After the initialization code terminates, it exits with
a normal exit() call and releases its memory, but control is returned
to the resident and the memory occupied by the initialization code is
freed.
Cheers,
Chuck
4:40 p.m.
Addition: here's probably how I would implement it given how you
described it and if I wanted to be quick about it. Of course some
pointer massaging may be in order if you're not in a memory model
where routine pointers and variable pointers are compatible.
-------------------------------------------------------------------------------------------------------
class init_vars {
// all your initialization variables. No pointers please.
// with an appropriate assignment operator.
};
const init_vars *init=(init_vars *)initialization_routine;
void initialization_routine() {
init_var *tmpvars=new(init_vars);
// do initialization stuff
// add noops here if necessary to pad the routine to sizeof(init_vars)
*init=*tmpvars;
delete tmpvars;
}
void end_of_initialization_routine() {} // for ease of calculating the size
// of the
initialization routine.
5:25 p.m.
In article <d67e42a90612281640h7a71e83dh796a428725a63127 at mail.gmail.com>,
"Eric J Korpela" <korpela at ssl.berkeley.edu> writes:
void initialization_routine() {
init_var *tmpvars=new(init_vars);
// do initialization stuff
// add noops here if necessary to pad the routine to sizeof(init_vars)
*init=*tmpvars;
delete tmpvars;
}
Classic case of abusing new/delete when all you need to do is declare
an instance of init_vars on the stack...
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
6:03 p.m.
New subject: TCP/IP Testing help
Greetings ..
I'm looking for a little help testing my TCP/IP implementation from a
friendly audience.
All you need to do is telnet to 24.159.203.149, port 2301.
24.159.203.149 is my Linux box, and it port forwards 2301 to my 386-40,
which is running my homebrew TCP/IP. You will get a small server
program that lets you see available memory, currently open socket
connections, and the DOS version & BIOS date of the machine the code is
running on.
Up to 9 people can connect simultaneously. I'm hoping to get a few
hundred connections from varying machines to see how it behaves.
I'd have run it on an older machine such as a 5150, but I am doing some
extensive tracing/logging in case anything bad happens, that I didn't
want any performance issues.
Thanks in advance,
Mike
7:31 p.m.
New subject: TCP/IP Testing help
I'm looking for a little help testing my TCP/IP
implementation from a
friendly audience.
Works good from here.
--
--------------------------------- personal: http://www.armory.com/~spectre/ ---
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- If Ted Kennedy had driven a VW, he would be President now. -----------------
12:30 p.m.
New subject: TCP/IP Testing help
Michael B. Brutman wrote:
Greetings ..
I'm looking for a little help testing my TCP/IP implementation from a
friendly audience.
All you need to do is telnet to 24.159.203.149, port 2301.
24.159.203.149 is my Linux box, and it port forwards 2301 to my 386-40,
which is running my homebrew TCP/IP. You will get a small server
program that lets you see available memory, currently open socket
connections, and the DOS version & BIOS date of the machine the code is
running on.
Up to 9 people can connect simultaneously. I'm hoping to get a few
hundred connections from varying machines to see how it behaves.
I'd have run it on an older machine such as a 5150, but I am doing some
extensive tracing/logging in case anything bad happens, that I didn't
want any performance issues.
Thanks in advance,
Mike
Ok, it's broken! Testing is over for now ...
(The heap became corrupted sometime within the last hour. Time to start
reading traces.)
Thanks for all of the help. It wasn't as much traffic as I would have
liked, but it's broken just the same. :-)
Mike
12:27 p.m.
New subject: TCP/IP Testing help
It was thus said that the Great Michael B. Brutman once stated:
Ok, it's broken! Testing is over for now ...
(The heap became corrupted sometime within the last hour. Time to start
reading traces.)
Well, I did telnet in, typed a few commands, then typed a bunch of control
characters (like Ctrl-C) that seemed to break the simple program you were
running at the other end of the TCP connection. I didn't write anything
since it didn't seem like a TCP problem.
Thanks for all of the help. It wasn't as much
traffic as I would have
liked, but it's broken just the same. :-)
Hmmm ... do you support ICMP? A good test might be ping with huge
packets.
-spc (If you have access to a Unix system, nc (netcat) would be a good
utility to use as well ... )
3:30 p.m.
New subject: TCP/IP Testing help
Michael B. Brutman wrote:
Ok, it's broken! Testing is over for now ...
(The heap became corrupted sometime within the last hour. Time to start
reading traces.)
Thanks for all of the help. It wasn't as much traffic as I would have
liked, but it's broken just the same. :-)
Mike
And just for the record, the cause of the heap corruption was probably
me calling free twice on the same piece of allocated memory. I didn't
trace out the exact call flow that caused the problem, but I can see
where I could free the same buffer twice. And if you do that, TC++ 3.0
will report a corrupted heap.
I allocated the memory with malloc, not new, so C must be bad and C++ is
superior. ;-)
Mike
10:13 a.m.
On 12/28/06, Richard <legalize at xmission.com> wrote:
Classic case of abusing new/delete when all you need
to do is declare
an instance of init_vars on the stack...
That depends upon how large you made your stack and where it is. This
is MS-DOS, and you're trying to reduce overall memory usage, after
all. If a 1k stack is enough to handle your calls and returns, you
should keep large temporaries on the heap, then release the unused
portions of the heap back to the OS after initialization (assuming the
IP stack is implemented as a TSR.)
Eric
6520
days inactive
6527
days old
31 comments
11 participants
participants (11)
-
cclist＠sydex.com -
jwest＠classiccmp.org -
korpela＠ssl.berkeley.edu -
legalize＠xmission.com -
mbbrutman-cctalk＠brutman.com -
mouse＠Rodents.Montreal.QC.CA -
pat＠computer-refuge.org -
spc＠conman.org -
spectre＠floodgap.com -
trixter＠oldskool.org -
zmerch-cctalk＠30below.com