Re: [Freedos-user] Freedos 1.1 install errors...
Op 11-4-2012 21:33, Jack schreef: > Send me a private E-Mail, and if XMGR can be modified so Syslinux and > Isolinux do NOT "confuse" it, I will make such modifications in XMGR! I'll try to figure out what's going on, however have much doubt that I'd be skilled enough to actually find a root cause. A web view of the Syslinux files is available at: [ http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=tree;h=refs/heads/master;hb=refs/heads/master ] A 7MB zip-file of everything (contents uses long filenames!) : http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-4.05.zip Behaviour I'm noticing: * one A20 method if loading FreeDOS directly (bootsector, no syslinux) * another one if loading FreeDOS from Syslinux (chainload bootsector) * a 3rd one if going from Syslinux to MEMDISK to FreeDOS. JEMMEX's way might be the most compatible. A testing floppy would have the following: [1] FreeDOS bootsector pointing to MetaKern bootloader file [2] MetaKern bootloader including FreeDOS and Syslinux bootsectors [3] FreeDOS kernel/shell/xmgr/config.sys/autoexec.bat [4] ldlinux.bin (Syslinux) [5] freedos.bss (FreeDOS bootsector) pointing to KERNEL.SYS [6] memdisk (syslinux ramdisk driver) [7] fdboot.img (tiny floppy image containing above partially) with 3 boot test methods: * 1 --> 2 --> 3 (pretty simple). * 1 --> 2 --> 4 --> 3 (reasonably OK). * 1 --> 2 --> 4 --> 6 --> 7 --> 3 (complex). Bernd -- 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
Re: [Freedos-user] Freedos 1.1 install errors...
>>> ... With my own testing I found JEMMEX more compatible than XMGR >>> or HIMEMX + JEMM386 in various cases, but on other systems it is >>> different, as Mike mentioned ... >> >> To WHAT "incompatibilities" are you referring?? > > The A20 stuff that Syslinux/Isolinux (and MEMDISK) mess around with, > even before loading a DOS kernel.As your driver expects a sane > BIOS setting and sane behaviour of the DOS kernel, it's slightly > less tolerant/paranoid compared to JEMMEX. This is all at boot- > time (config.sys), not runtime (devload xmgr.sys) as no A20/HMA > stuff is involved then due to DOS (kernel-)limitations. I would like to know exactly WHAT kind of "insane" settings re: "A20" can be done by Syslinux/Isolinux, which would in fact "confuse" XMGR! Send me a private E-Mail, and if XMGR can be modified so Syslinux and Isolinux do NOT "confuse" it, I will make such modifications in XMGR! -- 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
Re: [Freedos-user] Freedos 1.1 install errors...
Op 11-4-2012 21:10, Jack schreef: >> ... 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 ... > > To WHAT "incompatibilities" are you referring?? The A20 stuff that Syslinux/Isolinux (and MEMDISK) mess around with, even before loading a DOS kernel. As your driver expects a sane BIOS setting and sane behaviour of the DOS kernel, it's slightly less tolerant/paranoia compared to JEMMEX. This is all at boot-time (config.sys), not runtime (devload xmgr.sys) as no A20/HMA stuff is involved then due to DOS (kernel-)limitations. Think I prepared a floppy image file sometime ago, but downloading that isn't very modem-friendly. Basicly I just have to verify behaviour of different sets of drivers under various systems and emulators. It's a long-term todo item. Bernd -- 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
Re: [Freedos-user] Freedos 1.1 install errors...
> ... 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 ... To WHAT "incompatibilities" are you referring?? Be advised of the following -- 1) JEMMEX/JEMM386 use "old" memory-test schemes, to remain compatible with that never-updated 130K atrocity known as MS-DOS EMM386! If using the JEMM drivers, specific "I=-"/"X=-" lines may be needed to avoid "new-style" areas of memory -- "I=Test" and "X=Test" might not be enough. 2) "XMGR + JEMM386" or "HIMEMX + JEMM386" should give nearly the same results for available memory. HIMEMX may find about 9K more, for it allows use of certain ACPI areas, while XMGR does not. But 9K bytes is not a big difference, given today's 4-Gigabyte systems! 3) "UMBPCI + XMGR" may well give far bigger differences in the memory it finds for use, since in this case UMBPCI "detects" upper-memory and XMGR then uses what UMBPCI found. I did not write UMBPCI but I believe its memory-test algorithms ARE rather different than the ones used in JEMM386/JEMMEX. 4) "UMBPCI + XMGR + JEMM386" can also be used, when one allows UMBPCI to scan for "normal" upper-memory (C8000h-Eh) and only desires JEMM386 to "map" the B-B7FFFh monochrome video space for extra upper-memory. But NOTE that this will NOT work using FreeDOS, as FreeDOS allows but ONE upper-memory "provider" and will not add-up the memory found by UMBPCI and JEMM386.MS-DOS V6.22 and V7.10+ allow multiple "providers" and will do such an add-up. -- 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
Re: [Freedos-user] Freedos 1.1 install errors...
Hi, On Wed, Apr 11, 2012 at 1:24 PM, Bernd Blaauw wrote: > Op 11-4-2012 20:02, Rugxulo schreef: > > 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. I'm no whiz myself, but the only way to learn is try, I suppose, or read a billion books and sources. Though it's not easy, and there just aren't enough helpful mentors. >> 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. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/cpulevel2007.zip >> 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. I built 9.22 with stock DJGPP + CWSDPMI only just to be safe with licensing. You can find it on iBiblio. Though it bundles CWSDSTUB in itself to ease use, but you can remove that if you want to save a few kb. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/7zip/7zdecode/ > A 386+ build of UPX-UCL v3.08 wouldn't hurt either :) I did manage to cross-compile it, but native DJGPP just didn't seem to like it, and I got too frustrated to keep trying ad nauseum. (I'm pretty sure they only cross-compile too, so they don't care about native builds.) So I never got back to that, hence iBiblio only has 3.07. But I can email or upload it for you if you want. It works fine. EDIT: Never mind, just uploaded to iBiblio, check here: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/upx/upx-ucl-3.08.zip -- 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
Re: [Freedos-user] Freedos 1.1 install errors...
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
Re: [Freedos-user] Freedos 1.1 install errors...
Hi, On Wed, Apr 11, 2012 at 11:13 AM, Eric Auer wrote: > >>> it seems even on modern hardware unpacking FreeCOM >>> during install may take VERY long, so we need a fix: >> >> This seems to be specific to the old installer (v3.7.8 by Jeremy) I >> think, as that unpacks entire packages. Sourcecode modification would be >> required to add a "-x source/*". Alternatively, or additionally, if >> someone modified the new installer (v4.01 by Jim) to switch to >> destination directory after unpacking files, that would also work. > > That sounds as if a very small problem keeps you from > upgrading to a newer and probably better installer... Yes, but Jim is too busy, and barring any motivation, others (ahem) haven't looked at it either. >>> - it is good to have source and binary in one zip > > If size is critical, you can automatically make zips > without sources by doing zip -d somefile.zip source/* Not recommended, it's easier to just keep it together. Though if you want to maximize size, just put sources inside their own .ZIP but within the main .ZIP, so at least unpacking only has to create one file. You can even use "Stored" (-0 compression) on it so the outer .ZIP can compress it better as a whole. >>> - but you can use info-zip's command line options >>> (-x source/*) to exclude sources from unzip :-) >> >> New installer already does this, reason why... > > That is sth. to discuss with the installer maintainer :-) Again, he's too busy with real life (work, MBA) and updating the web site, etc. >>> - a default install does not need sources, as the >>> user can always fetch those from the zip later >> >> I've never liked programs with many options/switches > > Exactly. So do not ASK users whether and which sources > they want to install, just TELL them that all sources > can be found in the zips when needed. Users will rarely > need sources and most of the time only of single apps. 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.) >>> - users should be warned that install without XMS >>> drivers will be horribly slow due to lack of RAM > > Regarding the compatibility trouble discussion: Users > BELIEVE that not loading drivers is a safe option but > in fact it is a very problematic one because the install > performance totally chokes on lack of memory then. You > could better offer multiple XMS drivers to chose from. 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. 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. > For not loading anything, there is always the F5 key... Yes, but some DOS settings are quite limited by default, so sometimes F8 is better. >> I intend to offer loading of XMS driver at runtime as an option. > > Please avoid that - it complicates things and does not > give FreeCOM or kernel enough extra RAM to matter. So > I strongly prefer loading XMS drivers in config.sys... I agree with Eric, but it's your call, Bernd, obviously. ;-) > As said, XMS drivers should be loaded in config.sys, > there can be several XMS drivers to pick from to get > extra compatibility, and avoiding XMS drivers should > be hard, so only expert or masochist users do it... Depends on the app. Most "extended" apps can support raw just fine (more or less). Hmmm, spawning other extended apps might be tricky in some scenarios, but only because of fragmentation or default allocating everything for parent app. >>> Excluding sources from unzipping instead of unzipping >>> and then deleting them also saves CPU time and disk >>> activity time and temporarily disk storage space :-) >> >> Deleting files can take ages indeed. By the way, I'm considering >> 7-zipping sourcecode of programs that can't be compiled in DOS. > > We hopefully do not have many such programs anyway...? What can't be compiled in DOS? I know a lot of DJGPP-era stuff needs LFNs, but I can't think of any common FreeDOS util (off the top of my head) that can't easily work. Well, there's probably something somewhere. 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). -- Better than sec? Nothing is better than sec when it comes to monitor
Re: [Freedos-user] Freedos 1.1 install errors...
Hi Bernd, >> it seems even on modern hardware unpacking FreeCOM >> during install may take VERY long, so we need a fix: > > This seems to be specific to the old installer (v3.7.8 by Jeremy) I > think, as that unpacks entire packages. Sourcecode modification would be > required to add a "-x source/*". Alternatively, or additionally, if > someone modified the new installer (v4.01 by Jim) to switch to > destination directory after unpacking files, that would also work. That sounds as if a very small problem keeps you from upgrading to a newer and probably better installer... >> - it is good to have source and binary in one zip If size is critical, you can automatically make zips without sources by doing zip -d somefile.zip source/* >> - but you can use info-zip's command line options >>(-x source/*) to exclude sources from unzip :-) > > New installer already does this, reason why... That is sth. to discuss with the installer maintainer :-) >> - a default install does not need sources, as the >>user can always fetch those from the zip later > > I've never liked programs with many options/switches Exactly. So do not ASK users whether and which sources they want to install, just TELL them that all sources can be found in the zips when needed. Users will rarely need sources and most of the time only of single apps. >> - users should be warned that install without XMS >>drivers will be horribly slow due to lack of RAM Regarding the compatibility trouble discussion: Users BELIEVE that not loading drivers is a safe option but in fact it is a very problematic one because the install performance totally chokes on lack of memory then. You could better offer multiple XMS drivers to chose from. For not loading anything, there is always the F5 key... > I intend to offer loading of XMS driver at runtime as an option. Please avoid that - it complicates things and does not give FreeCOM or kernel enough extra RAM to matter. So I strongly prefer loading XMS drivers in config.sys... > request to have a tiny init shell that spawns, in a loop FreeCOM That is easy but makes things complicated compared to just loading XMS drivers when XMS drivers SHOULD load. I think I once made some "CMD" for that when FreeCOM had a bug that made it exit from time to time :-p As said, XMS drivers should be loaded in config.sys, there can be several XMS drivers to pick from to get extra compatibility, and avoiding XMS drivers should be hard, so only expert or masochist users do it... >> Excluding sources from unzipping instead of unzipping >> and then deleting them also saves CPU time and disk >> activity time and temporarily disk storage space :-) > > Deleting files can take ages indeed. By the way, I'm considering > 7-zipping sourcecode of programs that can't be compiled in DOS. We hopefully do not have many such programs anyway...? Eric -- 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
Re: [Freedos-user] Freedos 1.1 install errors...
Op 10-4-2012 18:21, Eric Auer schreef: > it seems even on modern hardware unpacking FreeCOM > during install may take VERY long, so we need a fix: This seems to be specific to the old installer (v3.7.8 by Jeremy) I think, as that unpacks entire packages. Sourcecode modification would be required to add a "-x source/*". Alternatively, or additionally, if someone modified the new installer (v4.01 by Jim) to switch to destination directory after unpacking files, that would also work. > - it is good to have source and binary in one zip There's some disadvantages though, download size being one of them, memory size and loading times in other specific conditions. A 16MB binary-only ISO has its merits also. > - but you can use info-zip's command line options >(-x source/*) to exclude sources from unzip :-) New installer already does this, reason why this new installer isn't unconditionally enabled yet is that I dislike having to search entire partitions for a single (post-installation) file just to find out where files were installed to. > - a default install does not need sources, as the >user can always fetch those from the zip later I've never liked programs with many options/switches, so confusing and often also lacking examples. > - users should be warned that install without XMS >drivers will be horribly slow due to lack of RAM I intend to offer loading of XMS driver at runtime as an option. (JEMMEX LOAD or DEVLOAD XMGR.SYS). However this doesn't solve low memory situation as FreeCOM can't relocate itself. Hence my perhaps decade-old request to have a tiny init shell that spawns, in a loop FreeCOM in a non-permanent way, so FreeCOM can be started a second time automatically if exiting the first FreeCOM instance. With that, automatic relocation to XMS. SHELL=TINYCMD.COM C:\COMMAND.COM C:\AUTOEXEC.BAT > - actually I would not even OFFER a boot menu item >to skip loading the XMS driver at all: You cannot >even boot the install CD / USB on old pre-XMS PC. > > Excluding sources from unzipping instead of unzipping > and then deleting them also saves CPU time and disk > activity time and temporarily disk storage space :-) Deleting files can take ages indeed. By the way, I'm considering 7-zipping sourcecode of programs that can't be compiled in DOS. Saves a bit of space. -- 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
Re: [Freedos-user] Freedos 1.1 install errors...
> Have you tried explicit "I=-" and "X=-" commands with > JEMM386/JEMMEX?? I've tried several different JEMM options -- none of them fixed the problem on that particular computer. I finally just gave up and went to other alternatives. -- 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
Re: [Freedos-user] Freedos 1.1 install errors...
>> actually I would not even OFFER a boot menu item to skip loading the >> XMS driver at all: You cannot even boot the install CD / USB on old >> pre-XMS PC. > > Probably a bad idea for compatibility reasons, unless you offer multiple > choices for which XMS manager to install. E.g., I have a computer where > JEMM doesn't work at all, but some of the others (including MS > HIMEM.SYS) do. Have you tried explicit "I=-" and "X=-" commands with JEMM386/JEMMEX?? Both of them were designed to use "ancient" EMM386 memory detection schemes, for compatibility reasons. However, newer devices and/or BIOS routines may require that JEMM386/JEMMEX are told to "avoid" their upper-memory address areas. Re: loading with no XMS driver, that can still be a useful diagnostic scheme, and I continue to permit UIDE/UIDEJR (but no-longer UIDE2) to be run in such a configuration. -- 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
Re: [Freedos-user] Freedos 1.1 install errors...
the "no-drivers" choice, No. 4, is provided because some programs, such as PLoP, will not load at all unless there are *no drivers* loaded, at least on my system... PLoP chokes on any drivers in freedos 1.1, saying: "cannot run under windows in a dos box", in effect. i kid you not. .. eufdp...@yahoo.com eufdp...@yahoo.com eufdp...@yahoo.com eufdp...@yahoo.com eufdp...@yahoo.com ..-- 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
Re: [Freedos-user] Freedos 1.1 install errors...
> actually I would not even OFFER a boot menu item to skip loading the > XMS driver at all: You cannot even boot the install CD / USB on old > pre-XMS PC. Probably a bad idea for compatibility reasons, unless you offer multiple choices for which XMS manager to install. E.g., I have a computer where JEMM doesn't work at all, but some of the others (including MS HIMEM.SYS) do. -- 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
Re: [Freedos-user] Freedos 1.1 install errors...
Hi Bernd, it seems even on modern hardware unpacking FreeCOM during install may take VERY long, so we need a fix: - it is good to have source and binary in one zip - but you can use info-zip's command line options (-x source/*) to exclude sources from unzip :-) - a default install does not need sources, as the user can always fetch those from the zip later - users should be warned that install without XMS drivers will be horribly slow due to lack of RAM - actually I would not even OFFER a boot menu item to skip loading the XMS driver at all: You cannot even boot the install CD / USB on old pre-XMS PC. Excluding sources from unzipping instead of unzipping and then deleting them also saves CPU time and disk activity time and temporarily disk storage space :-) Eric -- 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
Re: [Freedos-user] Freedos 1.1 install errors...
Op 8-4-2012 19:44, Michael B. Brutman schreef: > Some of us figured out that on ancient hardware (8088, 80286, etc.) the > decompression process takes a long time. If you are running in a > virtual machine and your underlying hardware/operating system does not > fully support virtualization then you are emulating the machine > instruction by instruction, and that can take forever too. Yeah Jim Hall insisted on combining source and binary into a single package so I've done that. The advantage is GPL-requirements are easier met this way, disadvantage is unpacking takes longer. Unpacking on a system without XMS-driver loaded from CONFIG.SYS is a nightmare, caused by a lack of memory. As FreeCOM can't relocate itself once XMS is available, we're in trouble and UNZIP gets very small decompression buffers. I've seen this happen with TDSK also taking 100KB low memory. > My 2009 vintage Intel quad-core supports virtualzation well so I have > very little instruction emulation. But a user with a newer Atom tried > it and noticed the horrible slowdown. Apparently the Atom isn't fully > capable of virtualization so QEMU was resorting to emulating each > instruction, and that is very slow. I think I mentioned somewhere FreeDOS installer unpacking everything in 28 seconds, but that was with C: a RAMDISK and the FreeDOS CD contents also in ramdisk, using SHSUCDRI. That's real hardware, I still have to test in virtual machines and make things more robust. Bernd -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Freedos 1.1 install errors...
On 4/3/2012 1:18 AM, Michael Robinson wrote: > There is a syntax error message that flashes before the where to install > freedos to and from menu comes up. Another problem, install freezes at > installing command.com. Uge! > Are you installing on old hardware or in a virtual machine? Some of us figured out that on ancient hardware (8088, 80286, etc.) the decompression process takes a long time. If you are running in a virtual machine and your underlying hardware/operating system does not fully support virtualization then you are emulating the machine instruction by instruction, and that can take forever too. My 2009 vintage Intel quad-core supports virtualzation well so I have very little instruction emulation. But a user with a newer Atom tried it and noticed the horrible slowdown. Apparently the Atom isn't fully capable of virtualization so QEMU was resorting to emulating each instruction, and that is very slow. Mike -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Freedos 1.1 install errors...
Hi, On Tue, Apr 3, 2012 at 1:18 AM, Michael Robinson wrote: > > There is a syntax error message that flashes before the where to install > freedos to and from menu comes up. Another problem, install freezes at > installing command.com. Uge! I'm pretty sure it was agreed upon that it doesn't technically "freeze", it just takes a (relatively) long time at installing FreeCom, for whatever reason. Just be patient, and it should finish. -- 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
