On Thu, Sep 6, 2012 at 11:50 PM, Rugxulo <rugx...@gmail.com> wrote:
> On Wed, Sep 5, 2012 at 5:50 AM, Rugxulo <rugx...@gmail.com> wrote:
>> On Wed, Sep 5, 2012 at 2:14 AM, Felix Miata <mrma...@earthlink.net> wrote:
>>> Is FreeDOS HD access as slow as PC or MS DOS? IIUC, the latter use slow 16
>>> bit BIOS code, which is what makes it painful for me to use compared to
>>> running DOS apps in an OS/2 VM.
>> Yes, probably just as slow as it also uses the BIOS.
>>> Is FreeDOS disk I/O in the same class as 32 &
>>> 64 bit operating systems speed-wise?
>> No, FreeDOS is pure 16-bit, but with Ultra DMA enabled and a software
>> cache (e.g. UIDE) can help a lot. That's about the best you can do
>> outside of just running under DOSEMU or similar (NTVDM).
>> BTW, things like DOSLFN slow down file accesses a lot, so avoid them
>> if possible.
I'd be interested in what Felix is doing and where he sees visible slowness.
As you mention, FreeDOS is 16 bit code. But how fast things will
appear to be will have more to do with the hardware you are running on
than whether the code is 16 or 32 (or 64) bit.
HD access varies depending upon the drive and the BIOS. The old
notebook I run FreeDOS on is hobbled, because the HD is IDE 4, with an
18 mbit/sec transfer rate. This is a BIOS limitation, so I can't just
swap in a faster drive. FreeDOS flies, but Windows and Linux notice.
I remember the old MS-DOS days where I would do things like change the
interleave value on a drive for faster operation. By default, disk
blocks allocated to files were stored sequentially - 1,2,3,4,5,6,,,.
The problem was that the machine might not be ready to access block 2
when it came under the drive head after reading block 1, and you would
have to wait for the drive to rotate and the block to come under the
head again. Reordering the blocks, like 1, 3, 2, 4, 6, 5... gave the
machine time to finish loading the first block before the second came
under the drive head, and you didn't have to wait a full drive
rotation for it to happen. You got a nice I/O boost. It has been a
long time since I was concerned with such things. :-)
On a current machine with a multi-ghz CPU and an IDE 6 or SATA drive,
I'd be a bit startled at perceptible slowness in file I/O, even with
16 bit code running. The faster the underlying machine, the faster
the code will run, even it it's 16 bit.
Better performance under something like DOSEMU isn't really a
surprise, as it's essentially a virtual machine, and the actual file
I/O is being passed to and performed by the native routines of the
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
Freedos-user mailing list