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 * xcdrom instead of udvd2 * sys 3.6 instead of 3.7 or 3.8-test >> * 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 > Anyway, I fixed it, and updated the binary on the boot image. The bugfix > will be part of the next FDNPKG release (which should happen soon by the > way). Thanks for fixing. > 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. Emulators make things difficult. Dosbox and Rpix86 have very strange behaviour for driveletters, filesystems and memory behaviour. > 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) But do keep things simple, better a mostly-working environment that's released, instead of something over-engineered but never-released (like I have). > I think you got lost because of the memory bug. Now that it's fixed, > FDNPKG usage should be quite intuitive. 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. > I'm not sure I understand what you are saying.. Yes, a harddisk is > required indeed... since the goal is to install FreeDOS on a hdd. 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. > Are you suggesting emulating a C: drive with a RAMdisk, and installing > FreeDOS there? What would be the real life use case? Are you thinking > about some kind of full-blown automated FreeDOS RAM-powered livecd, like > what Knoppix does with the 'toram' boot option? Just put SHSURDRV.EXE on the bootdisk image, and you'll get there. 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. > That's a very good point - I will synch since now on the floppy image on > iBiblio separately, too. It's named 'boot.img', and it's in the same > location as the CD image: Thanks! I'll get the FDNPKG from there. > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/ ------------------------------------------------------------------------------ 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