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.


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!
Freedos-user mailing list

Reply via email to