ts@uwasa.fi (Timo Salmi) (06/30/91)
In article <1972@contex.contex.com> avinash@felix.contex.com (Avinash Chopde) writes: >I need to port a program I wrote for UNIX machines onto the IBM PC. >I have the Turbo C++ compiler, and at first, I just tried to >recompile all the sources, but the compiler complained about >a struct being greater than 64K in size! >Now, I'm sure I'm doing something wrong, surely there must be some >way of defining large arrays. >Is there ? : I've only used Turbo Pascal, so this is just a tentative answer. In TP one has to go around the 64K limitation by a judicious use of pointers (I have a FAQ collection to cover how). But doesn't Turbo C have what is called a huge model (a rhetorical question). ................................................................... Prof. Timo Salmi Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.12.37 School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
colburn@tessa (alex colburn) (06/30/91)
In article <1991Jun29.203704.8443@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes: >In article <1972@contex.contex.com> avinash@felix.contex.com (Avinash Chopde) writes: >>I need to port a program I wrote for UNIX machines onto the IBM PC. >>I have the Turbo C++ compiler, and at first, I just tried to >>recompile all the sources, but the compiler complained about >>a struct being greater than 64K in size! >>Now, I'm sure I'm doing something wrong, surely there must be some >>way of defining large arrays. >>Is there ? >: > >I've only used Turbo Pascal, so this is just a tentative answer. In >TP one has to go around the 64K limitation by a judicious use of >pointers (I have a FAQ collection to cover how). But doesn't Turbo >C have what is called a huge model (a rhetorical question). With a huge model you may have static data total more than 64k BUT each module must have less than 64k. Also any pointer to a data structure larger than 64k must be explcitly declared as huge char huge *ptr. If you don't do this a reference like ptr[64k + x] will only try to increment the offset and not the segment of the address. A real pain in the ass, and usually resulting in a reboot. even if you do declare everything as huge, you still have to watch out for things like fread which expect a far pointer in the huge memory model. I called Borland and it is a bit confusing, even though they have something called a huge memory model, this model doesn't implicitly convert all pointers to huge. So fread can only handle 64k chunks of data at a time. My solution to all of this is to buy a new compiler. Borland isn't going to offer a 32 bit compiler until the OS2 version. At the moment I'm looking into Zortech's new 32 compiler with DOS extenders. It is my impression that this should make all of my memory allocation problems imposed by DOS much less of a hassle. Allocation of > 64k to the size of all system memory should be completely transparent. Does anyone have experience with DOS extenders and 32 bit compilers? I'd like to hear any info on the subject. Alex.
pshuang@athena.mit.edu (Ping-Shun Huang) (06/30/91)
In article <1991Jun29.203704.8443@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes: > In TP one has to go around the 64K limitation by a judicious use of > pointers (I have a FAQ collection to cover how). But doesn't Turbo C > have what is called a huge model (a rhetorical question). I think the following table is correct: MEMORY MODELS (IBM-PC C-compilers nomenclature?) ~~~~~~~~~~~~~ Tiny near data near code [note: same 64Kb segment] Small near data near code Compact near data far code Medium far data near code Large far data far code Huge far data far code [note: 64Kb+ data objects OK] [Note: near means total must be less than 64Kb, far means total can be more.] -- Above text where applicable is (c) Copyleft 1991, all rights deserved by: UNIX:/etc/ping instantiated (Ping Huang) [INTERNET: pshuang@athena.mit.edu]
trier@cwlim.INS.CWRU.Edu (Stephen C. Trier) (06/30/91)
In article <PSHUANG.91Jun30005831@w20-575-108.mit.edu> pshuang@athena.mit.edu (Ping-Shun Huang) writes: >I think the following table is correct: No, it is not quite correct. In any memory model except tiny, one may allocate _heap_ data objects larger than 64K by using the "huge" keyword. Your static data items (anything but "auto" and malloced space) is limited to 64k or less in every memory model but huge. In huge, it is limited to 64k per source file. Again, this "huge" keyword works in the small, medium, compact, large, and huge memory models. It looks and acts just like a far pointer. It's just slower. [Editorial: I am told that Microsoft has a mechanism that allows the allocation of huge static (not malloced) data items. Borland may also have such a mechanism. I have never bothered checking, because my programs tend more towards mallocing space as needed.] Huge memory model does _not_ imply huge pointers. The overhead of a huge pointer is very large, so making it the default in huge model would cripple huge-model programs. This behavior is identical in Microsoft and Borland compilers. If you are tight on space, you might want to try using a _smaller_ memory model. My experience has been that most programs that fit in MS-DOS at all will fit in a small, compact, or large memory model, depending on how much data and code is needed. The difference in size between small and huge models may be a factor of two or more, so moving to a smaller memory model (if possible) may actually increase your available memory. Likewise, the smaller memory models run much faster than the larger ones. The huge model is especially slow. -- Stephen Trier "48 61 70 70 69 6e 65 73 73 20 69 73 20 61 Server Surgery Group 20 77 61 72 6d 20 68 65 78 20 64 75 6d 70 Information Network Services 21 20 20 3b 2d 29" - Me Case Western Reserve University Mail: trier@ins.cwru.edu