Problems reserving memory with the 'malloc' command

[anon856525]

Hi

I recently downloaded Turbo C v2.01 from the borland web site where
its being given out for free. Has anyone else tried this?

Ive been using it for some months now and hav'nt noted any probems.
its very usable even without the user manual. My one problem is when
reserving memory with the 'malloc' command in the huge memory model.
your only allowed 180k about with a small test program. other texts
claim that turbo c can use at least 1 meg. base memory is 640k and so
it means that at least 460k is being used by T.C., the OS, the program
in memory, ect....

I've also had some lock-ups with the program im working on when i
reserve over 60k.

Anyone know how much memory this version of TC can actualy use?

Thanks.

 

[jacob navia]

Hi

I recently downloaded Turbo C v2.01 from the borland web site where
its being given out for free. Has anyone else tried this?

Ive been using it for some months now and hav'nt noted any probems.
its very usable even without the user manual. My one problem is when
reserving memory with the 'malloc' command in the huge memory model.
your only allowed 180k about with a small test program. other texts
claim that turbo c can use at least 1 meg. base memory is 640k and so
it means that at least 460k is being used by T.C., the OS, the program
in memory, ect....

I've also had some lock-ups with the program im working on when i
reserve over 60k.

Anyone know how much memory this version of TC can actualy use?

Thanks.

You are using a 16 bit mode, DOS program that can use up to
500K maybe more, maybe less. Try running your programs after
unloading the development environment of course.

You can do BIG programs within that environment.

I wrote a lisp interpreter with it, using the overlay feature.
It featured most of Common Lisp, even with a bignum package
and graphics.

But it is COMPLETELY outdated now. You are wasting your time.
Fetch another compiler from the web and program under a 32 bit
system. There you can have a more sensible environment
(forget the "hug" model with its 400K and start programming
in the flat model with 2GB)

 

[Default User]

Hi

I recently downloaded Turbo C v2.01 from the borland web site where
its being given out for free. Has anyone else tried this?

Ive been using it for some months now and hav'nt noted any probems.
its very usable even without the user manual. My one problem is when
reserving memory with the 'malloc' command in the huge memory model.
your only allowed 180k about with a small test program. other texts
claim that turbo c can use at least 1 meg. base memory is 640k and so
it means that at least 460k is being used by T.C., the OS, the program
in memory, ect....

Compiler specific questions are not appropriate here. You need to find
a Borland newsgroup.





Brian

 

[Richard Heathfield]

(e-mail address removed) said:

Hi

I recently downloaded Turbo C v2.01 from the borland web site where
its being given out for free. Has anyone else tried this?
Yes.

Ive been using it for some months now and hav'nt noted any probems.
Good!

its very usable even without the user manual.
Agreed.

My one problem is when
reserving memory with the 'malloc' command in the huge memory model.
your only allowed 180k about with a small test program.

That sounds pretty huge to me. I forget - how big is size_t (bit count) in
Turbo?

other texts
claim that turbo c can use at least 1 meg.

Not necessarily all in one lump, though. In any case, as long as you can
create an object at least 32767 bytes in size, Turbo C has fulfilled its
conformance obligations.

base memory is 640k and so
it means that at least 460k is being used by T.C., the OS, the program
in memory, ect....

....Well, not necessarily. It is also possible that Turbo C is making those
memory assumptions about its environment (e.g. the amount of memory taken
by the OS), even though they may not be valid nowadays. No programmer is a
perfect prophet.

I've also had some lock-ups with the program im working on when i
reserve over 60k.

That might conceivably be due to bugs in your code, wouldn't you agree?

Anyone know how much memory this version of TC can actualy use?

It only *has* to give you 32767 bytes. Anything more than that, you should
treat as a welcome bonus.

 

[Richard Heathfield]

Default User said:

Compiler specific questions are not appropriate here. You need to find
a Borland newsgroup.

A topical reply was possible in this case. See elsethread. I invite you to
give some thought as to whether sending people packing is necessarily the
best way to teach them the value of standard C.

 

[CBFalconer]

I recently downloaded Turbo C v2.01 from the borland web site
where its being given out for free. Has anyone else tried this?

Ive been using it for some months now and hav'nt noted any
probems. its very usable even without the user manual. My one
problem is when reserving memory with the 'malloc' command in
the huge memory model. your only allowed 180k about with a small
test program. other texts claim that turbo c can use at least 1
meg. base memory is 640k and so it means that at least 460k is
being used by T.C., the OS, the program in memory, ect....

It has, IIRC, two possible requirements. The smaller is when it is
working entirely in memory and prepares object code that the
resident debugger can handle. This means that the basic IDE never
gets out of memory. The larger is when it always prepares the
object code on the disk, when it has the OS limitations only.

So look for options such as 'Compile to disk' and set them if you
need the space.

 

[Default User]

Default User said:

A topical reply was possible in this case. See elsethread. I invite
you to give some thought as to whether sending people packing is
necessarily the best way to teach them the value of standard C.

I'm sure you thought your reply was illuminating for the OP, but
somehow I doubt it.




Brian

 

[Richard Heathfield]

Default User said:

I'm sure you thought your reply was illuminating for the OP, but
somehow I doubt it.

Potentially illuminating, my dear chap, potentially illuminating. More
illuminating than telling him to push off.

 

[Default User]

Default User said:

Potentially illuminating, my dear chap, potentially illuminating.

You're entitled to your opinion.

More illuminating than telling him to push off.

You're entitled to your opinion. I disagree with it in this case. Far
more likely is that he is using his implementation incorrectly, and
Borland group could straighten it out for him.





Brian

 

[Antoninus Twink]

You're entitled to your opinion.


You're entitled to your opinion. I disagree with it in this case. Far
more likely is that he is using his implementation incorrectly, and
Borland group could straighten it out for him.

It's always fun watching two strutting peacocks pecking at each other!

 

[Kenny McCormack]

(Peacock #1 writes)
(And A.T. concludes)

It's always fun watching two strutting peacocks pecking at each other!

Yes. We call it "Welcome to another episode of ... 'CLC regulars,
eating their own!' ..."

 

[anon856525]

You are using a 16 bit mode, DOS program that can use up to
500K maybe more, maybe less. Try running your programs after
unloading the development environment of course.

You can do BIG programs within that environment.

I wrote a lisp interpreter with it, using the overlay feature.
It featured most of Common Lisp, even with a bignum package
and graphics.

But it is COMPLETELY outdated now. You are wasting your time.
Fetch another compiler from the web and program under a 32 bit
system. There you can have a more sensible environment
(forget the "hug" model with its 400K and start programming
in the flat model with 2GB)

Thanks to everyone for their advices.

To explain the situation, my computer runs Windows 95 and only has 16
MB of RAM, so I don't really need to move up to 2 GB address spaces

Actually I have some problem with my Windows installation, and it's
really slow and sluggish when I start up, and there's huge amount of
network activity - very expensive on ppm dial up So I usually just
boot up to good old MS-DOS.

There are lots of things I really like about DOS, like how you can
make a pointer and just write directly to video memory and whatever -
everything's too much more constrained in Windows.

Anyway I tried what people advised and found I could get up to about
400 KB or 500 KB by making seperate malloc calls instead of a big call
- weird, huh? So thanks for the suggestions.

 

[jameskuyper]

(e-mail address removed) wrote:
....

Anyway I tried what people advised and found I could get up to about
400 KB or 500 KB by making seperate malloc calls instead of a big call
- weird, huh? ...

Not particularly. Depending upon your implementation, it's not at all
unusual for the largest single block you can allocate to be
substantially smaller than the total space you can allocate if you do
so in smaller pieces.

 

[Flash Gordon]

To explain the situation, my computer runs Windows 95 and only has 16
MB of RAM, so I don't really need to move up to 2 GB address spaces

You would also find a number of the compilers that support larger
address spaces would not run on your machine.

Actually I have some problem with my Windows installation, and it's
really slow and sluggish when I start up, and there's huge amount of
network activity - very expensive on ppm dial up So I usually just
boot up to good old MS-DOS.

I *seriously* suggest you wipe your Windows install and build it again
clean and ensure that it is properly protected by a firewall. My initial
suspicion for those symptoms is that you have a virus which is sending
out spam. Seek help on a Windows95 group for this.

Anyway I tried what people advised and found I could get up to about
400 KB or 500 KB by making seperate malloc calls instead of a big call
- weird, huh? So thanks for the suggestions.

You might want to look up "memory models" in the documentation and/or
ask on a Turbo C group. There are good technical reasons for a limit of
64K (minus a bit for house-keeping information) but if the penalties of
going beyond that are worth it you *might* be able to get TC to allow
it. The hows, whys and wherefores are not topical here though.

 

[anon856525]

You would also find a number of the compilers that support larger
address spaces would not run on your machine.


I *seriously* suggest you wipe your Windows install and build it again
clean and ensure that it is properly protected by a firewall. My initial
suspicion for those symptoms is that you have a virus which is sending
out spam. Seek help on a Windows95 group for this.

Hi

Thanks for the advice. I don't have a firewall... however, I do have
all the latest patches for Windows, and I haven't been browsing any
bad websites, so I don't think it's likely to be a virus.

You might want to look up "memory models" in the documentation and/or
ask on a Turbo C group. There are good technical reasons for a limit of
64K (minus a bit for house-keeping information) but if the penalties of
going beyond that are worth it you *might* be able to get TC to allow
it. The hows, whys and wherefores are not topical here though.

Interesting! You don't think it could be that the "tiny" memory model
is selected by default?