Day after observation: I am getting an A: drive redirect when I try to copy
files by "COPY" command. One file will copy to the desired directory and
then it searches for the A: drive. Would this be a glitch from the
installer?
On Tue, Feb 2, 2016 at 8:35 PM, Jerome E. Shidel Jr. <jer...@shidel.net>
wrote:
>
> > On Feb 2, 2016, at 7:54 PM, Eric Auer <e.a...@jpberlin.de> 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
> > Freedos-user@lists.sourceforge.net
> > 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
> Freedos-user@lists.sourceforge.net
> 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=272487151&iu=/4140
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
