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
