🚀 go-pugleaf

fritz@hpfcbig.SDE.HP.COM (Gary Fritz (tmp)) writes:

>In comp.os.msdos.programmer, timlee@public.btr.com writes:
>>Others, using MSDOS extenders, avoid the 640K limit and segmented
>>pointers, and have 32 bit ints.

>Are you saying that the "32-bit" compilers you list do NOT have to deal
>with the near/far/huge stuff?  Do they do this by always generating the
>worst-case "far" code?  From my (admittedly limited) understanding of
>the DOS world, the braindead segmented Intel architecture forces you to
>either pay attention to segmentation, or accept fairly serious efficiency
>losses.  Or am I misunderstanding you?

>Maybe I need a clearer understanding of what an "MSDOS extender" is...

Yes.  You need a little bit more information... It's a rather common 
situation too so don't think you are the only one that missed out.  
I get a lot of technical calls at work from people asking "how can I do
[something]" where [something] is best done with a DOS extended application.
DOS extenders exist in two forms, 16-bit and 32-bit.  

The 16-bit extenders allow you to run on '286 and above machines and 
access up to 16 Mbytes of memory, all just as if you were compiling 
with a standard large memory model.  You can malloc up to 64K in any 
single block, but instead of being limited to 10 or less such mallocs
(640K), you can keep on requesting heap up to the actual physical 
available RAM (2M?  8M?) up to 16M.  Similar things are possible with
the code size, all without overlays.

The 32-bit extenders allow you to run on '386 and above machines and
access up to about 4 Gbytes of memory (some extenders are intentionally
'crippled' and only allow something like 16 M).  These extenders let you
malloc up to the physical available memory in a single call -- 
malloc(1000000) is entirely reasonable.  Some 32-bit DOS extenders have
virtual memory capability too (in their uncrippled form).  You can 
malloc() (or run code) larger than physically available memory, up to 
approximately the amount of free disk space you have available.  Also,
the pointers are typically near pointers, but they are 32-bit near 
pointers (far pointers are 48-bits).  These 32-bit near pointers mean 
that access to data via this pointers runs much faster and with smaller 
code size because the segment registers don't have to be loaded everytime
you access a different pointer.

The drawback to 32-bit DOS extenders is that 1) Microsoft and Borland
don't currently have compilers that support 32-bit DOS extenders (16-bit
extenders -- yes, 32-bit -- no).  2) Many of the uncrippled 32-bit 
extenders have royalties associated with them.

FlashTek (the company I work for) sells one of the few uncrippled, royalty
free, 32-bit DOS extenders available.  Currently, it only supports
Zortech, but other compiler support will be available soon.  You can get 
a free demo disk by sending me some email and your snail mail address.

-- 
netcom!proto!joe
joe@proto.com