Hi, On Mon, Apr 22, 2013 at 2:31 PM, Eric Auer <e.a...@jpberlin.de> wrote: > > Hi Jim, > >> unfortunately, freedos doesn't support anything over 8GB > > Please explain. It supports up to 2 TB with LBA. Maybe you > mean the size of individual files, limited to 2 or 4 GB.
IIRC, FreeDOS only supports file of approx. 2 GB, no higher. There is currently no (weird, buggy) support for Win9x 4 GB files. (Ask Eric for details.) DOS386 often raves about EDR-DOS' FAT+ working on big files, if you desire to investigate that (though "commercial use" of such a thing is probably not supported). Though you have to do it manually, there is no transparent support (e.g. in DJGPP libc). Most DOS users don't need it badly enough, I suppose. LFN stuff (and especially newer tech like exFAT) is patent protected. And developers for FreeDOS are very very few and often busy (hi, Jeremy, Bart, Eric). >> on x64 and maybe i386, even if support for BIOS should go away and >> only UEFI and x64 remains > > You can use DOS on x64 systems because they are i386 compatible. > > You can also use DOS on multi core or even multi CPU systems > because they have at least one CPU with at least one core. > > Note that DOS will "only" use the first 4 Gigabytes of your RAM, > as no DPMI which supports more is available. And only 1 CPU core. I think 4 GB is a bit optimistic. You can only "safely" use whatever your "extender" (or DPMI host or whatever) and/or memory manager (and/or BIOS) supports. Sometimes this is 2 GB, other times you can use 2.9 GB, maybe you're lucky and can use 3.5 GB. Dunno. IIRC, DJGPP libc chokes (by default) on address spaces over 2 GB (without manual sbrk calls). Even CWSDPMI r7 has some bugs that are still unfixed (but in the works). Eventually CWSDPMI (last I heard) plans to implement PAE support for up to 64 GB. It "should" (in theory) workaround any "memory holes" up to 4 GB (but doesn't always work in practice). > You can always use free open source compilers to compile your > commercial products. So DJGPP could actually be quite okay for > you. You could run some compiler on 64bit Linux or Windows for > making 32bit DOS apps, if you want to avoid running compilers > in DOS windows inside your Linux or Windows, or on plain DOS. Yes, cross compilers exist. Yes, GCC can (in theory) support it for DJGPP target. Some existing builds for Linux exist. Windows? Apparently almost nobody bothered so far. (One guy had to download DJGPP patches for GCC 4.8.0 before it would build correctly. Dunno, very skeptical that it builds easily under Cygwin, so I never bothered.) Sure, it's cool, but it's of limited use as you can't actually test under x64 OSes anyways (well, unless DOSEMU x64 or DOSBox work well enough for your app ... or maybe VBox + FTP server). So it's only really useful if you intend to test to see that compilation hasn't broken since various code changes or want to provide automated builds (latest trunk, perhaps) over the Internet (e.g. YASM, back in the day). Yes, sometimes cross compilers can build stuff faster than native DOS compilers (e.g. "make -j4") though installing DOS compilers atop a RAM disk can work wonders, even with UIDE already loaded. > Maybe DJGPP, MinGW, OpenWatcom... But then, the performance is > quite okay if you compile with a normal DOS compiler version, > in DOS or Windows or a DOSEMU box in Linux, in particular when > a ramdisk is available for the heavier parts of compiling... Yes, as mentioned. :-) And while I haven't followed OpenWatcom lately (esp. since Google Groups no longer mirrors their messages) and they haven't had any major release lately, they have always been top notch in supporting full cross-compiles from (almost) any host OS, even to/from DOS. (Though I don't suppose you can "build" OpenWatcom on pure DOS yet. One guy halfway tried a few years ago but never fully implemented any such patches for it.) >> - I would like to see a windows-nt/7/xp-ized kind of long filenames >> for the filesystem. it can fall back to 8.3, it works with floppies,I >> think it's the numeric tails system with NT, but I could be wrong. >> windows 9x/me not quite compatible with this I think (except for cd > > Actually Windows versions which do use long file names support > them on all FAT and NTFS disks, including floppy. When you use > such disks with DOS without loading long file name drivers, the > long names are not visible and you see 8.3 with numeric tails. There are workarounds, even without drivers (DOSLFN, StarLFN, etc.), e.g. TestDisk. So you can always roll your own manual support, if motivated enough! IIRC, everything after WinNT 4.0 (1996) supports LFNs and also FAT32, e.g. Win9x, Win2k, etc. You can actually disable 8.3 numeric tails for minor speedup, but it's not really recommended. (Not sure if Win64 does this or not, probably some weird corner cases somewhere. Still sad that Win64 can't support binaries besides its own stuff. I guess this is where using standardized, portable programming languages is a big win.) > When drivers are active, or in Windows or Linux, the opposite > happens: The 8.3 names are hidden and the long names are shown. I don't know if they're "hidden", just that usually they aren't directly exposed to users in default tools. You can still access the file with either name. > Note that for CD / DVD / BD you have other systems for long file > names, so it can happen that your operating system has drivers > for harddisk / floppy / flash but not optical, or vice versa. Dunno, you mean Joliet / Rock Ridge / whatever? Wasn't there some minimal limit to (very basic ASCII) filenames using only so many (8?) subdirectories and only 32 char filenames? Can't remember (and far from expert anyways). >> - support exFAT/fat64 OR support FAT32 to 32GiB (due to age-old >> microsoft bugs/limitations which still exist, the filesystem can >> handle 8TB). - support for 4k or larger sectors... > > Note that exFAT is not similar to FAT at all apart from having > FAT in the name and that you cannot get a free license IMHO. It was apparently meant more as a slimmer / faster replacement for NTFS on flash drives (less overhead). Yeah, patented, it's a pity. "Just use Li..." (slap!) > The EDR DOS hack for FAT32 (and some similar hacks, mostly > by DVD diskimage processing software, for Windows) to make > it support file sizes above 4 GB would be nice to have, yes, > although it has some limitations - you have to look at the > FAT chain to know the true size as the directory entry only > has the lower 32 bit of the size. DVD image files (and mostly only useful for HD re-encoding, right?) are the only real-world use case that is constantly mentioned for needing to support greater than 4+ GB files in FreeDOS. And as such optical media support is already a bit difficult (not the least of which is proper ASPI driver support), it makes it less appealing to developers. > Support for larger sectors is nice in the long run, but more > or less all disks available at the moment can still be used > with 512 byte sectors even when they also support 4k sectors. Yes, but there's always somebody trying to push newer tech with alleged claims of faster speed, etc. (which always impresses the tech savvy users who can't wait to upgrade to get 32 GB of RAM, 8 TB of SSD, etc. etc.). > Note that larger sector disks might require UEFI booting, as > I have doubts that MBR BIOS support is smooth for those. The > BIOS might just prefer to use the 512 byte sector view there. Again, most people don't need more than 2 TB, esp. not DOS users! ;-) > Talking about which, support for UEFI GPT partitions would be > both very nice and reasonably easy to add, as data structures > are not overly complicated. We can skip all non-FAT partitions > and similar advanced objects. > > I do have doubts that 2 TB of DOS data can be downloaded ;-) Dunno, it's surprising to me how many megabytes / gigabytes are often pushed upon consumers. (e.g. Why does VBox by default bundle 32-bit and 64-bit into one installer? Is that really superior to having separate downloads?) > Note that a POS terminal software and DOS easily fit 1 GB CF. Apparently wasting space is even easier for most people, though! ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
