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 -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
