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 problems? > 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): http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/ cheers, Mateusz ------------------------------------------------------------------------------ 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! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
