> On Feb 2, 2016, at 7:54 PM, Eric Auer <[email protected]> wrote: > > > 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!
It really isn’t needed. > > 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 :-) No reason, someone can not create an simple batch called something like GOLIVE.BAT that could be included with the CD ISO. It could handle all of that post-boot. Also, with how the installer is designed. A drop in could even be included to do it when the user exits the installer without performing an install. > >> 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! The entire installer is modular, customizable and extensible. Other than at startup with language selection and initial target verification, the installer performs no further actions until the user makes the final “install now” selection. This with drop in package lists, advanced mode, error handling screens and all of the other steps it takes during execution. All logic is handled inside the batch files that make up the installer. There is a rough draft developer manual on the github source page that goes into basic detail on what most of the different parts of the installer handle. > >> 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. Actually, the installer already does this in automatic target drive detection. That is how it knows to install to D: automatically. But, on some systems the USB drive is not C:, the installer automatically targets C:. It shouldn’t be difficult to include some of this logic into the initial (for settings import) TEMP directory setup. > >> 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 :-) Absolutely, but this is some of what you would loos from the current installer. Modularity with simple drop in extendibility. Text file lists of packages would be hard coded. Progress percentage could be done but all values would have to be calculated and hard coded for every single package removal and install. No backup progress possible. Import settings like DOSDIR and LANG from previous installation would have to go. There are many things that would make the install process less pleasant. > >> 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. It does it through batch magic and with the power of a V8. :-) It only imports the LANG setting and the subdirectory the user prefers for their OS C:\FDOS, C:\FREEDOS, etc. Jim, wants as few questions a possible during the normal install process. This at least reduces it by auto-detecting the users language when it they bothered to set it on their previous installation. In advanced mode, the user can opt-out or at least change lots of stuff. Including don’t replace config files, don’t transfer system files. > > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-user > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
