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 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 1:24 PM, Bernd Blaauw bbla...@home.nl 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...
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...
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...
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...
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...
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...
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
[Freedos-user] Freedos 1.1 install errors...
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! -- 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 Tue, Apr 3, 2012 at 1:18 AM, Michael Robinson plu...@robinson-west.com 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
