>> Why? After all, it would be a special kernel binary used to >> boot CD-ROMs only, so you would usually want to load both. > > Oh okay. Well in THAT case I think I would prefer one of two > other methods: 1. Add very basic readonly root directory file > read ability for ISO9660 CD/DVD to the kernel,
However this requires major code re-writing for this new driver, instead of relying on working drivers. (Which only requires the kernel to have this drivers's files embedded or on a boot disk image.) > maybe using NO > typeable drive letter: If the kernel detects it is booted from > CD/DVD, it would use a letter after Z (you can have 32 drives) > for that special driver and set the current drive to that, so > you can use "DEVICE=ELTORITO.SYS" and "INSTALL=SHSUCDX" without > having to mention drives or directories... Well, just add support for the well known drive letters [\]^_` into the kernel and that's it ;-) > That need not be hard... You could for example say that the 2nd file > has to start with MZ (shsucdx.exe and any other exe)... After all, > the whole theory is very specialized towards eltorito/shsucdx anyway > and eltorito.sys happens to have no misleading MZs inside either ;-). Sounds fun but isn't really reliable. Another ELTORITO.SYS version could easily include such a "misleading" MZ. Future versions of SHSUCDX (you said 6 KiB?) could easily be assembled into a .COM executable as well. > Writing new tools or modifying UPX for only one single file will > only annoy UPX developers You could release it as fork (or patch) if they don't want to include it in their distribution. > or waste time of the new-tool-writers. Don't we waste time anyway? >> Even if you did it with copy /B ... and then the UPX hack, >> won't it be easier for the user to use the build script to >> compile a new kernel which incbins the files instead of using >> copy /B and UPX manually? > > No. Another example is FreeCOM: You have a translation-friendly > command.com binary blob which you COPY /B before a message file > in your language and voila you have the complete command.com in > the language of your choice :-). Yes, but that appends only one file. Appending two files to the kernel raises the need to find where the second file begins. (If possible without unreliable signature searchs.) > There are also tools to create > message files. They, too, are easier to use and install than the > complex compile environment needed for command.com :-). Is it complex compared to the message file creator or complex compared to other compile environments? >>> But as said, I prefer not to put raw files in the kernel at all. > >> C design limitation? ;-) > > No, just a bad idea in general. And very incompatible because you > will have no useful information about the (nonexisting) filesystem > from which those files would magically emerge for use by the kernel > which still uses and IS DOS. I strongly prefer existing filesystems. You load these files once. I see no need to create a filesystem through which you could access these after booting. >>> Correct, kernel_start cannot copy more than 128 kB yet >>> but as always deep inside the kernel memory model and >>> startup code, structure is complicated and adding more >>> areas such as "embedded files" would make things a lot >>> more complicated. >> >> If you say so. I rather think when you already added support for 128 KiB >> data moving (requires accessing the data from two segments), more can't >> be >> that difficult. > > Well you can spend your own time on the project but do not > complain if it takes long or introduces new problems ;-). If it introduces problems they'll often be solutions for these problems as well. (Or you just avoid problems, which isn't difficult at boot time because you don't have to be MS-DOS compatible then.) >>>> This would require the kernel to be compatible enough >>>> to post-CONFIG state when only pre-CONFIG >>> I would not call this compatible, rather incompatible. >> >> Well, then someone would (!) need to *make* it compatible. >> DOS doesn't have to be incompatible to post-CONFIG. >> Because pre-CONFIG is so unknown no one even cares whether >> DOS is incompatible there. > > Drivers do care about DOS already being DOS when you run > the DEVICE lines. And DOS cares about already being DOS > when it tries to set up devices and run DEVICE lines, too. Well, "being DOS" doesn't seem to include "organizing memory in a chain of MCBs as DOS" in MS-DOS pre-CONFIG/CONFIG time. As shown by the recent tests with Debug there is only one MCB containing all low memory. If it's the same in DOS-C (I doubt it is) SHSUCDX couldn't load. Despite this, DEVICE= is executed during CONFIG time instead of pre-CONFIG. > You are of course also welcome to spend time helping to > solve mainstream problems at the same time, even if those > seem so normal, boring and non-interesting to you that you > fall asleep instantly when reading about normal problems ;-). In DOS no problem is normal ;-) >>> But feel free to politely ask Bart of nu2.nu to publish his sources >> I'll do so if I ever want to boot from a CD-ROM in no-emulation mode. > > Which includes boot with MEMDISK which is how FreeDOS 1.0 always boots. I meant, rather like "if I ever want to create a no-emulation mode bootable CD-ROM from scratch". Regards, Christian ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
