On 07/21/2013 12:06 AM, Bernd Blaauw wrote:
> Mainly the bootdisk programs:
> * kernel: 2036 instead of 2041
Updated to 2041.
> * xcdrom instead of udvd2
But is udvd2 really better than xcdrom ? What is 'user-perceived'
difference between these two?
> * sys 3.6 instead of 3.7 or 3.8-test
I think I got the sys that was packaged with the kernel 2041 - but I
will double check this.
> Yes: "load error: no DPMI - Get csdpmi*b.zip" upon invoking FDNPKG.EXE
Indeed, again testing on DOSemu doesn't showed me this, since DOSemu
provides its own DPMI service :) And it worked under VirtualBox because
I had an old HDD image attached on which CWSDPMI happened to be present.
I added CWSDPMI (r7) to the floppy. For future FDNPKG releases, I will
probably embed CWSDMI into the FDNPKG binary.
> I get errorlevel 64: "Error Reading Hard Disk: Search operation failed.
> Program terminated."
> fdisk 1.2.1 works.
As Rugxulo said, I don't know if downgrading is the best solution :/ But
if it works fine, then it looks like the easiest solution anyway.
> 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)
Okay, and would changing XCDROM by UDVD2 change anything with these
> I mean I basically get lost of how to get a list of available programs I
> can install. A bit of browsing, more or less.
> SEARCH already implies you as a user know what you want.
In fact, 'SEARCH' find all packages that are available for install, and
matches your search pattern. If you don't provide a search pattern, then
all available packages are printed.
I was wondering about creating a separate action for this, like LISTPKG
or something, but though it would be unnecessary... Now I see that it's
not as obvious as I though it was. If you have troubles it, then I'm
sure many people will.
> 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.
> Just put SHSURDRV.EXE on the bootdisk image, and you'll get there.
I see your point. Better to ship a binary that in worst case nobody will
use, than to limit the feature set of the boot image. Shsudrv is really
small anyway. I will add - but need to package it first and make sure I
got the latest version.
> Speaking of bootdisk..if people boot from their own boot medium
> (harddisk or some specific floppy) including CD access, they can't run
> FDNPKG as it's not in the data part of the CD ( X: ) but only in the
> bootdisk part (FDBOOT.IMG). A minor inconvenience for example on systems
> that can't boot from CD.
Sounds like a good idea as well. Not as easy as just putting FDNPKG.EXE
into the CD, since it needs to have a configuration file in a specific
place, but that's easy to solve - I will look into that.
I updated the floppy image and CD (for now only added CWSDPMI and
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