> I assumed you were talking about the functionality, not > about the files! For adding FILES into the kernel, you > would need something like that "very special boot image > of a ramdisk, inside the kernel binary" which needs extra > support both in the kernel (to make it visible with some > drive letter)
No. You could just load the contents of the files and execute them so you don't have to provide a letter. > as well as extra tools to generate such a > "kernel with diskimage" combined file in the first place. Well, when not using the disk image approach the kernel would have to know the exact position of the files anyway. You could just include the binaries in a NASM source file (think with incbin) and let NASM declare the position as global label. (Yes I know there are workarounds to create unsigned char arrays with hexadecimal values that represent the data in a C file but NASM's incbin is easier to use and doesn't fill source files with redundant data.) > Note that our boot sector already can boot > 64k kernels. If the kernel doesn't relocate itself later that's fine. If it does, the relocation code also has to handle > 64 KiB. > Also note that SHSUCDX is not meant to load from config > sys, you are supposed to load it after all device=X even > though you probably can load it before autoexec bat, by > using some install=... line for SHSUCDX. Yes. SHSUCDX is documented to work with INSTALL= (or INSTALLLAST= if available), but may not work when loaded as with INSTALL= but before processing CONFIG.SYS (and device drivers despite the embedded ELTORITO.SYS). CONFIG.SYS would (if not on an embedded disk image) be found on the CD-ROM so you would have to load both the driver and redirector before you can access the file. This would require the kernel to be compatible enough to post-CONFIG state when only pre-CONFIG, and possibly some special version of SHSUCDX. (I would try to avoid modifying SHSUCDX.) It would also require the CONFIG.SYS parser to skip CDS entries used by redirectors, because SHSUCDX is a redirector and it would be loaded before CONFIG.SYS (that's the same problem DEVLOAD currently has). Both driver and redirector would have to stay in low memory unless you also embedd XMM and EMM in the kernel/include it on the embedded disk image, or write some special code to relocate the driver (have to fix up pointers in SHSUCDX internal data, and the DOS device chain) and SHSUCDX resident part (have to fix up Int2F). Relocating SHSUCDX could also be done by preserving Int2F with another hook, and when UMBs are available, restore Int2F to SHSUCDX's temporarily, uninstall SHSUCDX, restore Int2F to actual chain (which doesn't include SHSUCDX anymore), and then re-install SHSUCDX into a UMB. This would also make relocation of ELTORITO.SYS easier because you won't have to fix up data in SHSUCDX during the time it isn't loaded. Well, if that all makes such problems, what's the point of not using an embedded disk image with the driver, redirector, XMM, EMM and CONFIG.SYS on it? Because the user would have to modify the kernel file containing the disk image each time CONFIG.SYS is to be modified or to use another XMM and EMM. (Though updating the driver and redirector would require recompilation/modifying the disk image in either case.) >> Why is the source code (of eltorito.sys) not available? >> If you'd really need it badly someone could disassemble it. > > That would not be polite. It is not available because > Bart of nu2.nu did not have the impression that the > work for making it available would be worth it, given > the apparently few people who have asked him yet :-) Aww. What a polite guy. 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
