Hi! >> Well that is still serious. Even if you do something as harmless as >> >> copy STUFF SOMEWHERE | more >> >> you would still end up 1. not seeing the output of "copy" and >> possibly even 2. block the "copy" process by stalling the pipe. >> >> In short, please use a ramdisk for all your pipe and temp work :-) > > Yeah, probably not going to do that. It adds to much complication > to the installer startup. It would need to be very small and that > may risk package installation failure later on with fdinst.
That is exactly why I recommend using a ramdisk: Without ramdisk, everything sent through pipes goes to a digital black hole when the install disk is not writeable, risking plenty of side effects. For piping stuff, a tiny ramdisk will be enough. If you assume that a computer which can boot from CD / DVD / USB has, say, at least 16 MB RAM (yes youngsters, not 16 GB ;-)) then you could use 4 for the cache and 1 for the ramdisk and have 10 left for installer / unzip 32 bit activities still. So a bit of a ramdisk is totally harmless! By the way, how about creating a 600 MB RAMDISK (no joke) whenever the installer detects 1 GB or more RAM? That would allow users to do a full install to the ramdisk, effectively using your installer stick as a "LIVE CD" without install and without rebooting :-) > if a user did not boot the install media and just runs it from > the command line, a pre-existing ramdisk may cause issues or be > forcefully unloaded. It is also an additional driver to load. Ramdisks are pretty compatible and I see no reason why loading more than one of them would cause any troubles. Also, my suggestion was to load a ramdisk in CONFIG & AUTOEXEC. Everybody who manually wants to start the installer from the command line of their existing DOS or Windows can be expected to know what they do, so I agree to not bother those by loading DRIVERS as side effect of installer start. Maybe this is a good topic for review! As the moment, which steps do you take in CONFIG / AUTOEXEC and which steps, apart from the scripted invocation of (after optional fdisk and format) the DOS package manager and the creation of a target config and autoexec, are taken by the installer itself? Thanks for giving an overview! > There is an easy way around the issue. I will probably just have the > installer test if C: is the USB stick prior to activating the TEMP > directory. That will not work with PLOP, nor will it work with "booting from a harddisk image on CD or DVD", as those are all write-protected simulations of a C: harddisk as far as my intuition tells me that. > The batch file based FDI installer would not be very good without any > pipes. It would have almost no flexibility at all. Would only have > hard coded package lists and would not be able to dynamically > create customized system configuration files. You can do a lot with errorlevels and you can select packages AFTER selecting the target drive: By definition, as soon as the user has selected (and maybe formatted) a target drive, you can write it :-) > At startup, it only uses C: if C: exists and is formatted. If those conditions > are met, It will check for system config files and import settings if they > exist. As explained, that is not sufficient to know whether it is writeable. >> Importing of settings? > > Language settings, DOS Installation directory \FDOS \FREEDOS \OS > or whatever. How does it try to grab those? If there already is FreeDOS on the target disk anyway, I suggest to NOT overwrite the autoexec nor the config by default: Instead, give the user a fresh example for those, in separate files. That way, the user can decide how they want to combine old and new config. Pre-existing DOS installs do almost ALWAYS have hand-made config changes and you would destroy those by "importing" the old into a freshly auto-created new set. Even if the pre-existing DOS install was created by some automated install tool and has barely been modified by the user later, your installer would still have to have knowledge about all installers which could have been used for the previously existing version, to know how and which information could be extracted from old configs. Regards, Eric ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
