Hi Bernd and all, > I finally got internet again, so after spending this afternoon reading > about 300 emails I'm back again.
I noticed that :-). > DEVLOAD /H /Q ATAPICDD.SYS /D:FDCD0001 > DEVLOAD /H /Q CDRCACHE.SYS FDCD0001 CDRCACH1 5 Oh boy... I still suggest using DEVICE, not DEVLOAD. The DEVICE method is the native one, DEVLOAD is only a kludge, and the UMB support of DEVLOAD is an even more ugly kludge. See my (direct) mail about a suggested simplified load system with: 8086 / 286: let user do anything to reach II. 386+: use boot floppy which boots the CD through SBM, reaching I. 486+, I.: boot the CD which boots (ISOLINUX/MEMDISK) a virtual DOS floppy which loads himem/emm386/eltorito/atapicdd/caches/... and jumps to the directory with the installer files. II. in the directory with the installer files (allow the user to do anything to get it accessible, including pre-copying it to the target PC with help of other operating systems), you have the final installer script. This checks for 'plain DOS (not Win) with FreeCOM (not less)', asks the user for some parameters like the target drive, and runs the make bootable part. The make bootable part repeatedly runs OSCHECK to decide whether to run fdisk/format/sys..., whether to backup previous boot sectors, whether to add FreeDOS to the boot menu of other OSes... This part can be left by the user / can abort in case of problems, and can be restarted at any point, checking the state of things whenever you start it. Then the installer asks for more parameters (e.g. target directory, language (for keyb, messages, display) and creates the config files. Finally either the GUI or the text 'installer ' program is started to unzip the FreeDOS components (after asking whether non-base categories / sources / ... are to be installed. For the sources, you should have all, none and only-some-as-selected...). For pre-386, the text unzipper/installer has to be used and the whole CD-ROM/cache stuff will not work anyway. BUT you can expect the user to be experienced enough with DOS to reach II manually in that case! The II...end part only has to block access to the GUI unzipper/installer and block usage of 386+ only drivers in the created config. No mount-an-iso is needed, no internet support is needed, the boot floppy can be downloadable separate (no create boot floppy is needed, there are image writing programs for DOS / Win / Linux, just offer those: DISKCOPY, ..., and a Linux dd howto). No conditional DEVLOAD is needed either. The drivers will simply fail to install if no suitable hardware is found, so DEVICE is good enough. For loading SCSI drivers, drop the user to a prompt and tell him how to use DEVLOAD and that he has to go to II when done. Do not try fancy prompt-for-filename-of-driver stuff, a plain DOS prompt is MUCH better for this than any batch file could be. For fdisk/format, always let the user in control. If OSCHECK thinks there might be an unknown OS, tell the user, and let him decide whether SYSing would actually damage an installed OS which we forgot to consider. You should not try to do everything automatically, in particular not with DOS. DOS users can think themselves, and better than our BAT scripts can. Handling the more common cases (CD-ROM or precopied files as source, boot in some way which reaches the CD-ROM in the end on a 386+) is more important than e.g. having a script which starts to spit out 360k floppy images after booting the CD-ROM on a 386 with only a soundcard CD-ROM IDE or even worse hardware... > 3) DISPLAY loads high and ATAPICDD/CDRCACHE load low, if removing the > REM from MEM /C in the beginning of autoexec.bat This is a really strange difference - MEM changing DEVLOAD effects. Maybe running MEM triggers some kind of garbage collection which modifies memory chains? Anyway, DEVLOAD is NOT recommended for everyday use. > here's a freed memory block but there's a PSP directly > following the MCB and that confused mem The above quote is for everybody who might have missed this conclusion to the "is there some 48k memory hole caused by KEYB" topic. Answer: NO :-). > FreeDOS kernel version 1.1.35w (Build 2035w-UNSTABLE, Sep 14 2004) > Kernel compatibility 7.10 - BORLANDC - 80386 CPU required - FAT32 support I would really like to have some half-official kernel which has all the well-looking bugfixes but not the experimental parts. It should also be either 8086+ or detect absence of a 386 and complain instead of crashing. Later in the install process you can offer the user to use the most recent experimental kernel. This will mean that the experimental kernels will be tested by more people. In either case, the VERSION= function should work. And of course I would love to have a kernel where pressing a digit to select a boot menu option actually selects that option! (Instead of only moving the focus there and waiting for an ENTER to confirm...) ;-P About DISPLAY: > UPX first, COM2EXE next, produces smallest size. bad idea. COM2EXE cannot detect de-UPX-ed size! So the exe header will tell how much space the compressed COM needs. But the whole idea of using COM2EXE was to let DOS know the de-UPX-ed size explicitly: UPXing EXE files has that ad*antage... If you load an UPXed COM into a too small memory block (or an com2exed UPXed com), you can end up in the situation 'upx stub sees that there is not enough memory, so it throws int 20 (exit with errorlevel 0, no message) instead of unpacking and running the program'... > All my testing is done in VMware 4.5.2, btw. No > Bochs/Qemu/DosEMU/VirtualPC etc. Bochs is easy to install but you would need disk image editing tools like mtools to copy data to/from the virtual drive I think. Qemu might be fast but it is kind of experimental... You should ask on the list if some people want to offer you test systems in a virtual way. It has been very helpful for FORMAT to have met some people whom I could send modified FORMAT versions e.g. daily and they reported back if things worked on their special (e.g. 720k/1200k/360k drive) hardware... Eric PS: About other threads... Kaspersky uses buggy YRDX 0.49? Then somebody should tell them to use 0.50 ... FreeDOS hangs but MS DOS keeps running? Then how is MS DOS affected by the ZRDX 0.49 bug? NCACHE2 only works if max 31.x MB XMS are free? Then in must be quite old, but luckily HIMEM offers a command line option to limit the overall amount of managed XMS. Check my online cache review to find out more about other older and newer caches, too ;-). MS DOS 6 enables CPU caches at boot time? Sounds like a strange idea, as you normally config that in BIOS and only disable caches if you have your reasons. DOS should not re- enable caches without asking first. Maybe make the function SWITCHES=... controlled. ------------------------------------------------------- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
