Op 11-4-2012 20:02, Rugxulo schreef: > Users will always need sources, esp. if they share, but they don't > necessarily need to unpack them. (Well, anyways, they probably don't > have all compilers anyways.)
The entire idea of opensource was to be able to modify sources to suit a person's needs. Most people, including me, haven't got enough interest or experience to be a programmer, but still, a bit of messing around and see what happens, should be possible. > Keep in mind that outside of FDXMS286, there is no XMSv2 only driver, > esp. for 286s that is the only one that (allegedly) works. And > obviously XMS doesn't work at all on 8086 or 80186. The combination of 01) System firmware (BIOS/EFI/UEFI/Coreboot) 02) Controller firmware (PCI IDE/SATA/USB controller) 03) Boot Manager (GRUB/Syslinux/Memdisk) 04) Boot Loader (boot sector usually) 05) Kernel (FreeDOS/MSDOS/DRDOS etc) 06) Shell (FreeCOM/4DOS) 07) Memory driver (XMGR/HIMEMX/JEMM386/JEMMEX 08) Other drivers (SHSUCDX etc) 09) Programs (KEYB, DEVLOAD UIDE.SYS) 10) Settings (DOS=HIGH / DOS=UMB / DOSDATA=UMB) can be horribly misbehaving in some cases. With my own testing I found JEMMEX more compatible than XMGR or HIMEMX + JEMM386 in various cases, but on other systems it's different, as Mike mentioned. My preference would be no XMS driver at all, and only load as needed/wanted. If the MEMDISK stuff in FreeDOS kernel 2041 works properly (guess it's not compiled in by default? not sure?) I could offer which memory driver to load already from the Syslinux menu. > But I thought the default installer (since on CD) was 386+ anyways? Or > at least default requirements. So just use DJGPP UNZIP32.EXE (or > whatever it's called), it can run in "raw" (no mem. managers) just > fine. If you really want, you can include both 16-bit and 32-bit > UNZIP*.EXE files and choose dynamically at runtime (cpulevel.com, if > errorlevel 3 unzip32.exe). At least this way won't be painful > "unnecessarily" for 90% of users. Copy proper decompressor somewhere and set path? Sounds like a nice option. > Yes, but some DOS settings are quite limited by default, so sometimes > F8 is better. PATH and DIRCMD usually come into my way. For others, language/keyboard stuff might be quite relevant as typing blindly on keyboards with different layouts is confusing. Yay laptops from Belgium :) > I agree with Eric, but it's your call, Bernd, obviously. ;-) Only done when needed (no C: present so offer FDISK if possible, or ramdisk which requires XMS which requires loading driver). >> We hopefully do not have many such programs anyway...? Flashrom is one such program at least. 4DOS might be another. > P.S. I guess you know 7zdecode.exe is much smaller than p7zip. Or are > you just letting the end user figure out how to unpack it? ;-) Oh > wait, p7zip itself can't build (easily?) on FreeDOS, heh, now that's > one behemoth of a package (slow to build). Your used extender for 7zdecwat.exe wasn't compatible with public distribution, so I can't use it. A 386+ build of UPX-UCL v3.08 wouldn't hurt either :) ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
