Op 28-12-2011 0:06, Michael B. Brutman schreef: > virtual machine to have 64MB of memory and a 500MB hard drive. > VirtualBox can emulate the PCnet Ethernet adapter, which is convenient > for us because VMWare does too.
yeah the tricky part is that it should be detected if a PCI adapter is present, and if so how many of which types. Just for fun, try a VM without harddisk. I implemented that as most current systems come without FAT partitions anyway (100% NTFS) > Just out of curiosity - Is JEMMEX (or any other expanded memory manager) > really required for an install? My impression of the install process is > that it is mostly a file copy or unpacking exercise. For the widest > compatibility not requiring an expanded memory manager would be a great > plus. I'll test if running without a memory manager is possible. I haven't had that much luck with several extended memory managers though. XMGR works fine for example but not when Syslinux and MEMDISK are involved, they mess around with the A20 line. > Fifteen seconds if you know what to expect. A newbie or a person who > installs infrequently is going to have to read the questions and ponder > them for a few moments. Do they need to fdisk again, or are they > satisfied with what they had? Do they think they need to load > additional optical drivers? I was splitting up detection in 2 types: * fast (VMware share, eltorito CD, harddisk ISO) , auto-detected * slow (PCI IDE/SATA , USB) , driver loading required. CD Driver would only be loaded in the following situations: 1) menu auto-timer expires, loading is automatic then. 2) no installation sources found, so try more devices 3) user selects to load CD-driver > After Fdisk runs (and changes are made) the installer should lead the > user to reboot the machine. At the moment it gives a warning that the > machine should be rebooted, but then it returns to the previous screen > where it asks if you want to run fdisk or load drivers. Instead it > should lead to a screen that says 'Reboot now, or go back to fdisk and > play some more'. How the reboot gets done doesn't concern me too much > as long as the user knows they need to reboot before trying the install > again to make sure the partitioned disk is now visible. I'm thinking about offering following options: 1) Restart system to continue installation 2) Run FDISK again 3) Use ramdisk > Do we need upgrades to CHOICE? I can do that. ; - 0 Sounds like an interesting offer. > Ok - I'm not alone here. A lot of machines might not even have > sufficient memory to create a ram disk; is this step necessary? (As in, > does it speed things up a lot?) I was able to install without this step > working, so that tells me it is not strictly required. Buffering is only offered if there's enough system memory. >>> Again, not confidence inspiring. D: was completely empty - I am not >>> sure what is supposed to be there. I've got a suspicion that the CD batchfiles also contain TDSK related commands (only run during low memory situations), thus ruining the ramdisk created by overriding settings. I'll investigate. > Is this another opportunity to write a little code? One thing I love > about all of this is that the source code is available .. if something > needs some tweaking we can fix it. A huge tweak would be a config.sys option to disable enumerating harddisk partitions. However that means: [kernel] -> [config.sys] -> [initdisk] -> [config.sys] -> [autoexec.bat] instead of: [kernel] -> [initdisk] -> [config.sys] -> [autoexec.bat] > What are we using - the old installer or the new installer? It depends. Like I said, try a VM with sufficient memory and no harddisk. The new installer lacks directory switching to the destination installation directory, and harddisk searches are slow. Thus, using old installer. However, when C: is a ramdisk, new installer is used as it's fast enough to search a ramdisk for POSTINST.BAT and switch to there. > Should packet drivers go in a separate directory during the install > instead of being lumped in with the core FreeDOS files? (I like to keep > things isolated, but that is just a personal preference.) I think Jeremy parked them in FD1.0 in its own separate subdirectory somewhere. > You are welcome. I appreciate the effort put forth so far, and I hope > that we can make this compelling enough to attract new users. Just for fun: * boot the CD till the blue Isolinux menu * select option 2 * hit TAB instead of ENTER * type " remaster" at the end (without quotes). This should start CD recreation process. That's the easy part. The hard part is finding a storage location for the updated ISO. I've not included Georg's DOSUSB drivers, but in my own FD1.1 copy it's present, thus allowing me at the syslinux commandline to add 'usb' or 'usb=X:' (and even ' usb=C: ' ) to assign a custom driveletter to the flash disk. > (Free)DOS isn't going to challenge Windows or Linux any time soon; > however it still generates interest from people who want to run older > applications or even just see how things "used to be." I think the > collectors/retro enthusiasts are mostly ignorant of FreeDOS and I'd like > to get them interested. Sounds like an interesting challenge. I'm defaulting to LiveCD mode for this reason. That means I want C: available for RAMDISK, which means DOS shouldn't assign driveletters to existing partitions. As all DOS flavors auto-assign it, my only option is to use the 'nopassany' parameter in isolinux, with the disadvantage of ruining CD access by ELTORITO as well. I hope all this technical work done so far will allow easy adding of more DOS software (browser, pdf reader, OpenWatcom, etc..). A bootable working compiler environment would be nice. I dislike figuring out all that stuff. Anyway, thanks for testing, to be continued once I got some time available. ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
