Subject: 64k limit ?????? data segment error .... 
Author Message
 Subject: 64k limit ?????? data segment error ....


Quote:
>HI,

>I`m getting a "data segment too large" error and I think it`s because I`m
>over the 64k limit. I used 25 arrays and a total of 383 objects. When the
>compiler gets to the 15th array ( or the 255th object ) I get the error.
>The array`s are made up of constant strings ( not integers ). Does anyone
>know any way to stop this error ??????

Only by setting up pointers to arrays and using GetMem / New to
dynamically use memory on the heap. It is *not* Possible to have a data
segment of more than 64K.
--

In principle,   is there uncertainty that
Heisenberg was working his best in chaos?
=========================================



Fri, 03 Dec 1999 03:00:00 GMT  
 Subject: 64k limit ?????? data segment error ....

Quote:


> >HI,

> >I`m getting a "data segment too large" error and I think it`s because I`m
> >over the 64k limit. I used 25 arrays and a total of 383 objects. When the
> >compiler gets to the 15th array ( or the 255th object ) I get the error.
> >The array`s are made up of constant strings ( not integers ). Does anyone
> >know any way to stop this error ??????

> Only by setting up pointers to arrays and using GetMem / New to
> dynamically use memory on the heap. It is *not* Possible to have a data
> segment of more than 64K.

That kinda depends on the compiler... Notise the cross posting... But,
since
he included .tPascal, is assume that's what he's got. And then, the
first solution
would be pointers.

type
    fooObject = object
                        ...
                end;
    fooObjectPtr = ^fooObject;

var
   fooArray: array[1..1000] of fooObjectPtr;

begin
     new(fooArray[1]);

     ...

     dispose(fooArray[1]);
end.

Something like that. You might alter it, if you use virtual methods

--
- Asbj?rn / Lord Crc

http://home.sn.no/~bheid/



Sat, 04 Dec 1999 03:00:00 GMT  
 Subject: 64k limit ?????? data segment error ....


Quote:
>HI,

>I`m getting a "data segment too large" error and I think it`s because I`m
>over the 64k limit. I used 25 arrays and a total of 383 objects. When the
>compiler gets to the 15th array ( or the 255th object ) I get the error.
>The array`s are made up of constant strings ( not integers ). Does anyone
>know any way to stop this error ??????

You can :

1) Split the data into different units.
2) Use pointers and getmem.
3) Make the strings smaller (Mystring : String[size]) if possible.

Hope this helps

--

 "How do you shoot the devil in the back?"
 "What if you miss?" -Verbal Kint
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



Sun, 05 Dec 1999 03:00:00 GMT  
 Subject: 64k limit ?????? data segment error ....

Quote:

>I`m getting a "data segment too large" error and I think it`s because I`m
>over the 64k limit. I used 25 arrays and a total of 383 objects. When the
>compiler gets to the 15th array ( or the 255th object ) I get the error.
>The array`s are made up of constant strings ( not integers ). Does anyone
>know any way to stop this error ??????

In 16-bit Delphi, the data-segment and the stack occupy a single 64K area.  
For this reason, most things are dynamically allocated.  For example, you can
define a "Global" object in a unit that is shared by all other application
modules.

The main program creates "Global" when the program starts and destroys it when
the program ends.

There is also a limitation that no single object can be larger than 64K.  
However, if you define "Global" as a Delphi class, you can design whatever
implementation you need in that one module and the rest of the program can
ignore the technical details.  There are a variety of container-classes
available.



Sun, 05 Dec 1999 03:00:00 GMT  
 Subject: 64k limit ?????? data segment error ....

Quote:

>>1) Split the data into different units.
>This must me one of the most common false advices in this group. It does
>not help as the data segment is global.
>>2) Use pointers and getmem.
>>3) Make the strings smaller (Mystring : String[size]) if possible.

>Osmo

What I usually do is to define one "global" object.  It's actually a class.  
It's created when the program starts and destroyed as it goes away.  

All of the things that the various units of the program need to talk among
themselves and to each other are stored in Global.  When the things that are
global need to be larger than 32K or so (even in Win95.. transportability is
still important to me), it becomes a method.  Voila, now the class hides all
of the details of physically locating and storing/retrieving the global
information -- exactly, of course, as a class ought to do.

It works.  Even in Win95-land, it works.



Wed, 08 Dec 1999 03:00:00 GMT  
 Subject: 64k limit ?????? data segment error ....


Quote:

>You can :

>1) Split the data into different units.

This must me one of the most common false advices in this group. It does
not help as the data segment is global.

Quote:
>2) Use pointers and getmem.
>3) Make the strings smaller (Mystring : String[size]) if possible.

Osmo


Thu, 09 Dec 1999 03:00:00 GMT  
 Subject: 64k limit ?????? data segment error ....

Amusing, isn't it? How many times do we have to muddle through someone's
post on the 64K limit? The first thing any programmer needs to do is
understand their tools and their "limitations." The second is to
understand the problem they want to solve and design an appropriate
solution.

For goodness sake, master using dynamic memory -- the heap wasn't designed
into the compiler for the heck of it. Think through memory use and
appropriately apply the available data types. For example, a programmer
who uses an unqualified string (equiv to string[255]) for a simple prompt
for a short string is wasting memory. Now for most app's, the waste isn't
noticed because there is memory to spare. However, if the program needs
to handle large amounts of data, thinking through the use of data types
and using dynamic memory should be part of the design process.

Applied once, qualifying string lengths won't do much. But in a larger
construct such as an array, the savings multiplies.

--
------------------------------------------------------------------
David Firth              N8PTK ! 52 45 41 4C 43 4F 4D 50 55 54 45
                               ! 52 53 48 41 56 45 4F 4E 4C 59 38



Thu, 09 Dec 1999 03:00:00 GMT  
 Subject: 64k limit ?????? data segment error ....

Dear David Firth,

Even you started one day programming. Please don't be a wiz kid but help
starters, that's what these groups are about. THERE ARE NO STUPPID
QUESTIONS, BUT THERE ARE SIMPLE ANSWERS.

Don't you remember your parents helping you with your first steps......

Niek Breur



Fri, 10 Dec 1999 03:00:00 GMT  
 Subject: 64k limit ?????? data segment error ....


Quote:
> THERE ARE NO STUPPID QUESTIONS

Stick around.

AME



Sat, 11 Dec 1999 03:00:00 GMT  
 Subject: 64k limit ?????? data segment error ....


: Even you started one day programming. Please don't be a wiz kid but help
: starters, that's what these groups are about. THERE ARE NO STUPPID
: QUESTIONS, BUT THERE ARE SIMPLE ANSWERS.

Point taken. Dynamic memory was a mystery at one time for me too. However,
the 64K limit is pretty clearly spelled out in the doc's. RTM, you know.

: Don't you remember your parents helping you with your first steps......

I was pretty young. I bet you don't remember either.

--
------------------------------------------------------------------
David Firth              N8PTK ! 52 45 41 4C 43 4F 4D 50 55 54 45
                               ! 52 53 48 41 56 45 4F 4E 4C 59 38



Sat, 11 Dec 1999 03:00:00 GMT  
 Subject: 64k limit ?????? data segment error ....

Quote:
> >>You can :

> >>1) Split the data into different units.

> >This must me one of the most common false advices in this group. It does
> >not help as the data segment is global.

> Oh really????

> Isn't it possible for an executable to declare more than one data
> segment (or am I talking rubbish).

   Insofar as TP/BP is concerned, this is rubbish.  8<}}  TP/BP allows
the use of only a single Data Segment, which it constructs from all the
(referenced) Var data declared in all the referenced Units and source of
the program.  You are allowed only (that infamous) 64K of such program
data - that which is declared as Var data, that is.
   However, some of that Var data can be Pascal pointers, so the actual
"data" used by the program can be allocated (stored) on the Heap - giving
the program capability to "use" much more than 64K bytes of "data".  You
must know how to work with Pascal pointers, though.
   Also, procedure-local data (Vars declared inside subprograms) can be
as much as has been reserved for the Stack - also a 64K total limit
there.  It's thus possible to use almost 128K of Var data, given the
structure of the program and how much local data is declared in higher
level subprograms.
   Finally, there's the concept called Smart Linking, where only
_referenced_ Var data is actually linked into the programs (which becomes
part of that 64K limit), and it's often likely that all the Var date
declared in a Unit isn't truly referenced by the program Using the Unit.  
A feature in TP/BP known as "Var blocks" (declaring data in multiple
Vars), "grouped" according to the programs which Use the Unit) allows the
Smart Linker to see only pertinent data when doing the link.  This
valuable technique isn't simple or easy to use, since one must know a lot
about how global Unit data is used and by what other programs and Units.
   Whew...

Quote:
> I don't know of any technical reason why the app can't declare more
> than one data segment..... enlighten me.

   There may not be any _technical_ reason, but that's how Borland
implemented the data aspect of their Pascal systems.  I believe it's so
the optimize data referencing by loading once and maintaining the
contents of a hardware register throughout the duration of the program's
execution.

Quote:

> I would think no more than 64k of data per unit, yes, but I'm sure
> I've made DOS apps with more than 64k overall.

  Yes, but not with TP or BP, I'm sure...8<}}


Sat, 11 Dec 1999 03:00:00 GMT  
 Subject: 64k limit ?????? data segment error ....

Quote:


>>You can :

>>1) Split the data into different units.
>This must me one of the most common false advices in this group. It does
>not help as the data segment is global.

Oh really????

Isn't it possible for an executable to declare more than one data
segment (or am I talking rubbish).

I don't know of any technical reason why the app can't declare more
than one data segment..... enlighten me.

I would think no more than 64k of data per unit, yes, but I'm sure
I've made DOS apps with more than 64k overall.

Martin Harvey.

***********************************************
Martin Harvey
Uni email:
6D 63 68 32 34 40 63 61 6D 2E 61 63 2E 75 6B
Home email:
6D 63 68 32 34 40 68 61 72 76 65 79 32 37 2E 64
65 6D 6F 6E 2E 63 6F 2E 75 6B
Decode the HEX back into ASCII chars.
Uni web pages: http://www-stu.pem.cam.ac.uk/~mch24/
***********************************************



Sun, 12 Dec 1999 03:00:00 GMT  
 
 [ 54 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. Subject: 64k limit ?????? data segment error ....

2. 64K Data Size Limits and CTE 49 {Data Segment}

3. 64k Data segment limit

4. BPW: data segment cannot exceed 64k

5. Error 49, Data segment too large

6. ERROR # XX ,DATA SEgment is too large

7. Help DPMI 64K Segment size

8. Organizing 64k heap-memory segments in real mode.

9. Static data size/data segment to large

10. Borland Pascal 64k Limit FAQ

11. rehash - the 64k limit problem

12. override 64k mem limit???

 

 
Powered by phpBB® Forum Software