Bernd,
I am going to try to snip the non-relevant (or the understood/agreed
upon parts) so that this doesn't get too out of control in terms of
length and lost trains of thought.
I used the latest VirtualBox (4.1.8) which is pretty close to VMWare in
function. I did not see anything that I suspect was related to
VirtualBox but I will try again in VMWare to be certain. I defined the
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.
On 12/27/2011 1:19 PM, Bernd Blaauw wrote:
> Op 27-12-2011 17:03, Michael B. Brutman schreef:
>
>> This check correctly found the hard drive with no partitions. But the
>> screen cleared too quickly; there should be a pause to show the results
>> of the fdisk check.
> Ah, so at least JEMMEX works for you, didn't build a failsafe around
> that yet. If a harddisk is found is shown again in text form at the
> central menu but I agree it could be more clearer.
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.
>> The next screen allows you to run FDISK to modify the hard drive
>> partition table or load additional drivers for optical drives. It tells
>> you installation will continue in 15 seconds. Once again that is too
>> fast, and there is no count-down timer to show you that the clock is
>> ticking. There is also no way to pause it if you need additional time
>> to read or decide.
> I thought 15secs to be sufficient for a single-choice, but can make that
> longer if desired.
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?
From a usability standpoint there should be plenty of time, a visible
countdown of some sort, and some way to pause the countdown. (This
applies in many places.) An advanced user can always blast through
without waiting. I put myself in the infrequent installer category, and
I needed more time.
>> Running FDISK was uneventful. But after FDISK exited it went back to
>> the previous screen ("run FDISK or load optical drivers"). FDISK gives
>> a warning about needing a reboot but does not enforce that. The install
>> script should terminate by telling the user that the machine is going to
>> be rebooted to restart the installation and actually reboot the machine
>> once the user acknowledges it. (No count-down timers!)
> How was FDISK uneventfull? I know v1.31 has some MBR-detection issues
> (blank disk in VMware for example) so using the older 1.21 one. There's
> an issue if FDISK can't find any disks, then it won't reboot either.
> Using FDAPM instead (there's a couple of hidden options basicly, like
> 'r' or 'm' or 's'). I'll see what I can change.
It just worked - no problems. The blank virtual hard drive in
VirtualBox did not confuse it all all.
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.
>> Resuming where I left off ...
>>
>> Mysterious "a" and "1" appear after the 15 second period. Next comes a
>> prompt about "Buffering installation files, press N to skip:" There is
>> no explanation about what is going to be buffered, or what the
>> ramifications are of saying "no". There appears to be a timeout period
>> that but it is not stated, and there is no countdown.
> I'm not sure how to implement a countdown, it's not an option in CHOICE
> program (and neither is suppressing the selected input char apparently,
> thus explaining the 'a' (auto-mode) and '1' displayed).
Do we need upgrades to CHOICE? I can do that. ; - 0
>> Next the RAM disk program runs and creates a drive (G: in my case), but
>> all of the operations to create directories and copy files to G: fail.
> I've seen this on my family's laptop during Christmas and will have to
> debug this, it's not happening on my machine. Quite odd. What happens is
> that a RDPREP.BAT file is being called on the CD that loads SHSUCDRD.
> The SHSUCDRI program (duplicate disk) didn't work for me so I went this
> route.
> I can try disabling this routine if that would be more failsafe.
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.
>> All of the messages are out there - it looks really ugly and would scare
>> the hell out of somebody. (I'm not a newbie but even I felt the need to
>> stop and debug what just happened, not realizing that the failures did
>> not affect the ability to install.) Any operation to drive G: gave an
>> "Out of memory error."
>>
>> The last prompt said:
>>
>> Type E:\Setup to start installation of FreeDOS 1.1.
>> Batchfile 'D:\AUTOEXEC.BAT' not found.
>>
>> Again, not confidence inspiring. D: was completely empty - I am not
>> sure what is supposed to be there.
> A: is the virtual diskette created by MEMDISK, C: is harddisk partition
> or left available for ramdisk by SHSURDRV.
> D: is the lowest driveletter that is assigned to a 100KB ramdisk created
> by TDSK (in XMS if available, otherwise conventional memory).
>
> The 100KB ramdisk is created because even the virtual A: can't be
> guaranteed to be writeable with enough free/available diskspace. What
> should happen is that the command interpreter gets copied to this
> temporary ramdisk as well as the main a:\autoexec.bat file.
Ok - that explains the error message out of context. I'll look to see
if the command interpreter was copied there.
>> Starting the install with E:\Setup ...
>>
>> After selecting the language there was a foul stream of "Run chkdsk: Bad
>> FAT I/O: 0x00000001" messages before the installer cleared the screen
>> and reported that the drive need formatting. The latter part was good,
>> but the foul stream of error messages really should be hidden. (And
>> whatever caused them needs to only show one message at most, not the
>> same message over and over.)
> I've not tried yet with an unformatted drive C:, will see if it gets me
> the same experience as you had.
Not a functional problem, but ugly. We must not scare new users. I
intend to get a lot of new users. :-)
>> "2) Change installation mode" should tell you what the current mode is.
>> It should also be above "1) Start installation of FreeDOS 1.1 Final",
>> forcing the user to read through it and consider it. The screen has
>> plenty of room for help text as the user moves through the menu options.
> No idea how to add help texts to PBATCH, sorry.
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.
If the help texts are not necessary then I wouldn't bother changing it,
but it did seem lacking.
>> Selecting option 1, a mysterious "Syntax Error" appeared on a blank
>> screen before continuing. Not confidence inspiring.
>>
>> The package selection screens should have some basic help - using the
>> arrows to move, 'X' means selected, etc. "Boot" was missing a
>> description - the rest were fairly spartan. "Done" probably should be
>> "Continue to the next step."
> The old installer is a bit messy indeed, and isn't always used. If you
> start SETUP with an argument (E:\SETUP DUMMY) you'll get the new
> installer (which however isn't that friendly either, lacking
> recommendations and defaults).
What are we using - the old installer or the new installer?
>> Second package selection screen: Everything has an 'x' at the end of it
>> which makes the 'x' kind of meaningless. If the description is too long
>> it corrupts the right border with extraneous letters instead of
>> continuing on the next line. (Dosfsckx does continue to the next line,
>> but the screen formatting is borked.)
> This is INSTALL 3.7.8 interpreting LSM files I think. The screen
> flickering isn't that nice either.
Ok - yet another thing we can fix ...
>> Upon rebooting FreeDOS wanted me to select boot options from a menu (0
>> to 4) but the menu options were missing. I've seen them before, so this
>> is just an oversight.
> Ouch, wonder how I managed that. Guess I should create a graphical
> step-by-step installation guide.
Graphical? No ... I don't think things are that bad. Just some
cleanup and tweaks to the install process. The best installers don't
need an installation guide; they are intuitive.
>> I took a quick look around and went straight for mTCP (of course). I'd
>> like to provide a more detailed configuration file that includes some
>> default options commented out. That would make it a lot more obvious to
>> somebody who is picking it up and looking at it for the first time.
> You're welcome, is this file already present in your most recent MTCP
> package? I remember there were some tuning/performance options as well.
I have a 'sample' configuration file that I distribute in mTCP; if
appropriate I would rather do one customized for FreeDOS. (I would not
put in every possible option and I would refer to the doc directory for
the advanced options.)
> I'm real bad with getting networking going on virtual machines (and my
> physical machine doesn't have a packet driver for its network card),
> only included the AMD/VMware packet driver so far.
The AMD packet driver is a good choice - it works on VirtualBox too.
Georg Potthast has a great packet driver collection too; I think a
subset of those would cover a lot of hardware. If we stick to the
CRYNWR derived packet drivers then we are still open source.
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.)
> Thanks for your feedback, much appreciated.
>
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.
(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.
Mike
------------------------------------------------------------------------------
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
