On Sat, Jul 20, 2013 at 5:06 PM, Bernd Blaauw <bbla...@home.nl> wrote:
> Mateusz Viste schreef op 20-7-2013 23:08:
>> Could you tell me please which software you see old?
> Mainly the bootdisk programs:
> * kernel: 2036 instead of 2041

Well, 2036 wasn't exactly horribly buggy nor super old (FD 1.0 in
2006), but anyways ....

> * xcdrom instead of udvd2

I profess complete ignorance of all the IDE / SATA / PATA confusion. I
never understood it, but I'm no engineer. Can someone please explain
which driver is best in which circumstance? By default, I assumed that
UIDE doesn't support SATA or PATA, only IDE (maybe only via legacy

In particular, GCDROM and XGCDROM are forks of XCDROM (predecessor of UIDE):


I'm 99% sure that Jack Ellis would strongly recommend against those
forks since they are based upon older, buggy code. But I'm not sure if
they somehow work better in non-IDE instances.

>>> * missing CWSDPMI.EXE apparently
>> Yes, cwsdpmi is not on the boot floppy. Mostly because it's not needed -
>> have you run into any kind of troubles because of the lack of cwsdpmi?
> Yes: "load error: no DPMI - Get csdpmi*b.zip" upon invoking FDNPKG.EXE

Was this intentional or just to avoid swapping to floppy or ... ? Of
course, you can bind CWSDSTUB.EXE to the .EXE (and/or use CWSPARAM to
disable swapping entirely). It's still fairly small.

>> What's happening exactly? I'm not really a VMware aficionado, never
>> tested FreeDOS with this. Is it some kind of a 'known bug' specific to
>> FDISK and VMware? What solution would you suggest?
> I get errorlevel 64: "Error Reading Hard Disk: Search operation failed.
> Program terminated."
> fdisk 1.2.1 works.

Meh. I'm not sure that's a good thing. Perhaps one of us needs to ping
Brian R. again?

Or you could (should?) also include / try XFDISK and/or SPFdisk ??

> Emulators make things difficult. Dosbox and Rpix86 have very strange
> behaviour for driveletters, filesystems and memory behaviour.

DOSBox has its own DOS and doesn't use FreeDOS. Unless you're thinking
of "BOOT"?

Rpix86 presumably means something like QEMU on Raspberry PI. (QEMU
still has various bugs regarding segmentation, probably since it's not
needed for Linux emulation.)

>> Is it because of the XCDROM.SYS ? I'm no expert here, but aren't SATA CD
>> drives acting as some kind of 'emulated IDE' ? Or does it mean that the
>> boot image would need a special SATA driver, and some detection logic to
>> load the right driver? This starts to sound complicated :P
> Yes, and a lack of DOS drivers for various controllers/interfaces is the
> main culprit. The CD driver works for IDE and for SATA in legacy mode.
> Now imagine having only an USB CD drive on a system.
> (or something emulating it, like a Zalman hdd-caddy, or ISOSTICK)

Didn't someone integrate eltorito.sys into isolinux a few years ago?
Doesn't that help somewhat?


> I'm not sure anymore nowadays the goal is installing FreeDOS on a
> dedicated system, but rather to have it available and to use it, when
> necessary. What I mean to say is, people will boot from your CD, then
> find out their harddisk is partitioned 100% already for Windows. Thus,
> no easy way to get a drive C: available.

Unavoidable without some (limited) NTFS driver. Maybe GRUB4DOS can
boot a DOS image file created as one contiguous block file? But how to
create that ... dunno, someone may have to write it (not me!).

But anyways, Windows since Vista lets you optionally resize the NTFS
partition, so it's no big deal. (Also RUFUS can install FreeDOS to
bootable USB stick.)

See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
Freedos-user mailing list

Reply via email to