Re: File Limits

[Bryan J Smith <b.j.smith@ieee.org>]

On 18/01/11 14:16, Xavier Tarifa wrote:  
> The standard limits for 32-bit Linux programs is 2GB per file, even
> though ext3 allows much, much more total space (and file size).

Large File Support (LFS) on 32-bit POSIX implementations was addressed almost a 
decade ago, including in Linux.

You must have three (3) things:  
1)  Kernel 2.4 (or a late 2.2 release with the backport, circa Alan Cox's 
2.2.18+, some earlier)
2)  GLibC 2.2 (or a late 2.1 release with the backport, circa 2.1.3+)
3)  A program or build solution that implements the LFS macros for 32-bit 
programs

For network file systems:  
- NFS v3 or later (including SGI+Trond backports to Alan Cox's 2.2.18)
- Samba 2.2

Most programs written in the last decade should implement #3, and it's fairly 
easy to do so in C code.  Most interpreters also do.  Unless you are explicitly 
typecasting 32-bit ints, it's fairly easy to do #3.  Any most any releases 
starting with Red Hat Linux 7 and later do all of the above.  I even had a 
GLibC/kernel running on Red Hat Linux 6.2 from VA Linux that offered such.

However, for Windows itself, you must be using the new xFAT for >2GiB file 
sizes, or >4GiB file sizes on NT kernels (a special call, not legacy compatible 
-- NT offered a 4GiB capable FAT16 file system as well).  Just having FAT32 is 
not enough.  xFAT is heavily patent encumbered though, and not Real Mode DOS 
compatible.

On 18/01/11 14:16, Xavier Tarifa wrote:  
> Have you tried using a 64-bit Linux and matching dosemu version?

I don't think that would work because x86-64 processors in Long Mode, as I 
understand it, do not support Virtual86 Memory Models.  Memory Models define 
library/program compatibility.

Long Mode uses a 48-bit "flat" (again, "long") instruction pointer where the 
segment register (16-bit) is concatenated with the offeset register (32-bit).

Protected386 and Virtual86 uses a 32-bit "normalized" instruction pointer where 
the segment register (16-bit) is the segment where the offset register (32-bit) 
is "flat."  Real86 uses a 20-bit "normalized" instruction pointer where the 
segment register (16-bit) is the segment where the offset register (16-bit) is 
"flat."

So as I understand it ...

Protected386 is compatible with Virtual86 memory models and can execute Real86 
programs.
Long Mode can execute Protected386, but cannot provide Virtual86 compatibility 
and execute Real86 programs.

SIDE NOTE:  This is also why x86-64 Long Mode cannot execute 386Enhanced models 
(shunts processor between Protected386 and Real86).

Long Mode actually uses Physical Address Extensions (PAE) paging, 52-bit to be 
exact.  It can provide up to 52-bit/1PiB addressing with flat pages of up to 
48-bit/256TiB sizes, although there are some flat 40-bit/1TiB and 36-bit/64GiB 
limits in some structures (especially on Intel processors, and AMD before the 
Processor 10h series).

PAE was originally introduced with the Pentium Pro and uses 36-bit, providing up 
to 36-bit/64GiB addressing with flat pages up to 32-bit/4GiB.  In other words, 
there is a "hard" limitation at 52-bit/1PiB "paging" and 48-bit/256TiB "flat" 
address models in the current x86-64 Long Mode memory model where it will break 
even Protected386 (32-bit) compatibility.

It's all about memory models.  I could be wrong though.  Does DOSEmu provide 
emulated Real86 compatibility when the processor is in x86-64 Long Mode?

-- Bryan

P.S.  HyperVisors and virtualization will likely be the solution when 48/52-bit 
limitations are hit in hardware.  HyperVisors will no longer be optional, but 
required and ubiquitous.

-- 
Bryan J  Smith     Professional, Technical Annoyance 
Linked Profile:   http://www.linkedin.com/in/bjsmith 
---------------------------------------------------- 
UCF Basketball:   AP #23, ESPN/USAToday #22, RPI #17
UCF Football:   AP #21, BCS #25, ESPN/USAToday #20