> On Oct 17, 2015, at 7:16 PM, Michael Brutman <[email protected]> wrote: > > Disclaimer: All final judgement is withheld until the final product is > available. The video looks reasonable so far.
Just wait until you see a video of what goes on in “Advanced” mode. :) > > > I think we should be providing the ability to install sets of related > packages and individual packages. One size fits all will not work on small > systems. People should not be forced to accept everything. We don't need a > full package dependency manager; most DOS packages are fairly self contained. > But any installer in the year 2015 should provide this kind of function - > one size does not fit all. The one size fits all philosophy will make it > unusable on small machines. > > Batch files and return codes are clunky: > > - It is hard to keep state when everything has to be passed around as a > return code. It makes 'Oh, let me go back a screen and answer that last > question differently' difficult. Of course if you have no back button in > your installer then there is no problem, but I think that is a problem too. There are more ways to pass data around than just using errorlevel (exit codes). Mainly, I referring to I/O redirection. It has it’s limitations as well. However, it does greatly expand what can be accomplished. At present, (Back) button support has not yet been implemented in V8Power Tools. But, they are on the roadmap. Due to the design of the installer, a back button will not be an issue for it. > > - Using batch file utilities to draw a screen seems like a terrible solution. > On a slow system it is going to be painful. Although I have not tested it on a “slow system”, it probably won’t be that bad when booting from the install media (floppy, CD or whatever). Mainly, this is because the installer and all V8PT utilities have a very small memory footprint and the boot media is a little tweaked. (using floppy read caching an stuff) Originally, I was using default FreeDOS 1.1 config for booting. But, I realized that by not loading the JEMMEX memory manager performance increased exponentially. > > - Error handling is very limited. > > - Every batch file will have to be touched or duplicated for every language > the installer will support. That sounds terrible compared to a traditional, > properly internationalized program. FreeDOS users speak many languages. > (Ugh .. I should start fixing mTCP for this same reason.) > Possibly, but I have some ideas on reducing these issues. > > You've set the direction to make it simple and have suggested an > implementation based on batch files. Based on my software development > experience this is a mistake, but of course I reserve the right to be > incorrect. I hope it works out but if it doesn't we'll have people trying to > work around problems or worse, just not caring and moving on. A good install > experience is very important and not being able to choose what gets installed > seems fundamentally wrong. > > I agree that a good installation experience is very important. (I have absolutely no knowledge of any facts and the following is just my opinion, please don’t be offended) But, most people who will be using the OS are going to do so just for fun. They will download the latest version, boot their virtual machine and mostly want a complete operating system installed with little or no interaction. That way they can get on with playing that old DOS game they found in the cupboard or messing with any of the new toys that get shipped with the OS. They won’t want to pick this package or that package. They won’t know or care if it is using HIMEMX or JEMMEX. There will be some, who will be upgrading from 1.1. Most other installations will be in the vast minority. (end of opinion) At some point, I intend to create a vask and vchkbx utility for V8PT. With those, I will be able to add detailed package selection to the “Advanced” mode install process that is built into the installer. > > Mike > > On Sat, Oct 17, 2015 at 3:35 PM, Jim Hall <[email protected]> wrote: > >> On Sat, 17 Oct 2015 01:50:22 +0200, Jerome Shidel <[email protected]> > >> wrote: > >> > Hopefully, over the next couple days, I expect to have some free time to > >> > finish the FDI 1.2 batch installer. This does not include a couple > >> > advanced options. Such as altering the installation target or detailed > >> > package selection. Those will require me to finish V8PT first. > [..] > >> > If nobody minds skipping those advanced installer features and everyone > >> > gets motivated on getting release out, it could be a Halloween Edition. > >> > > > On Sat, Oct 17, 2015 at 9:14 AM, Matej Horvat <[email protected]> > > wrote: > >> Hold your horses. What about testing, to make sure it works in all edge > >> cases and when upgrading from 1.0 or 1.1? And localizing? The old > >> installer was available in several languages, so this one should be too. > >> > >> I'd also appreciate "advanced" features for the case when you want to > >> install e.g. one or two things from NET or UTIL in addition to BASE, but > >> not everything. Yes, there's FDNPKG, but what when you don't have a 386+ > >> and an Internet connection? > >> > > On Sat, Oct 17, 2015 at 12:48 PM, Michael Brutman <[email protected]> > wrote: > > +1 > > > > Also, I personally think the 'batch file setup' idea is deeply flawed. > > > > There is a balance to achieve. The more complicated a task is, the more the > > complexity should be hidden away in a few key places. An operating system > > is the canonical example of this; we build operating systems so that people > > can build programs or use them without having to do task and device > > management directly. An operating system installer which is to be used by > > millions [or in our case hundreds ;-) ] of people should try to hide as much > > complexity as possible. I don't think you can do that with batch files. > > > > Maybe I've misread what is going on. Is there a one page summary/design doc > > of what the new installer is supposed to do and how it is doing it? What > > are the target machines and what install media will be supported? > > > > > I had the idea when I was starting to write an update to the FreeDOS > install program, a while ago. When you take a step back to look at it, > the install program is a compiled program that reads a set of files, > queries the user for what to install, then unzips the packages into > the destination. And the FreeDOS install process is a set of smart > batch files that sets up the environment, calls the install program, > then does some cleanup. > > When I looked at updating the install program, I realized that the > install program didn't need to be a compiled program. We could do it > equally well with a smart batch file, using a set of enhanced batch > file tools. I put the idea out there, and Jerome picked it up. > > My ideal is that the FreeDOS install process should be greatly > simplified. I think the current FreeDOS install process for FreeDOS > 1.1 has too many steps. How many options do we need to provide? Is it > necessary to provide that much resolution to what packages to install > v not install? DOS Isn't that complicated. DOS isn't a big operating > system. It should be pretty straightforward to install DOS. > > I think the FreeDOS install process should be this simple: "Do you > want to install everything, or just the BASE packages?" "Do you want > to install source code too?" Once you've answered these setup > questions, the install process should be automatic. This makes the > installation really easy for the user. And it makes things easier for > us when people ask for help with FreeDOS - you don't have to wonder > what packages they might have skipped; either they installed > everything or they installed just the BASE. > > I've talked about it on the mailing list several times, and I've > reviewed it on my personal FreeDOS page > (http://www.freedos.org/jhall/). I think these blog posts are the > summary/ design doc you are looking for: > > > http://freedos-project.blogspot.com/2015/05/a-few-thoughts-on-simplifying-install.html > http://freedos-project.blogspot.com/2015/07/visual-batch-tools-simplifying-install.html > http://freedos-project.blogspot.com/2015/08/thoughts-on-updating-install-process.html > > > > Jim > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
