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 
updated kernel):


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