Hi! > No. You could just load the contents of the files and > execute them so you don't have to provide a letter.
You cannot "just load ... and execute", you would have to do it at the right moment etc. In particular, you would load SHSUCDX after all DEVICE lines, so you had to keep it waiting in RAM all the time. In addition, you want some user control, so it would be good if the files are "accessible like files" in config.sys to let you use the config.sys menu function if you ask me... But if you do really ask me, all this is getting much too complicated and you should just use MEMDISK with the files "really there in a real drive" (well as real as MEMDISK can get) so you have full flexibility and avoid the need to use exotic tools to create the disk image at exotic locations and avoid kernel changes. > 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. When really forced to combine things, I would just use COPY /B prekernel.exe + file1 + file2 prekernel2.exe before doing the UPX and header messing, also making the latter more advanced to know file sizes and offset etc. But as said, I prefer not to put raw files in the kernel at all. >> 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. 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. > 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. > 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... All this is getting so complicated and unusual that I would say you should at most try this in experimental operating systems, not in mainstream DOS kernels ;-). > 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.) Which is why I recommend non-embedded disk images with MEMDISK. The tools used to edit those are included in every Linux and easy to get for Windows users. No new tools would be needed. >>> Why is the source code (of eltorito.sys) not available? ... > Aww. What a polite guy. No, just a normal guy. Making sources available is work, and if nobody pays you and nobody even asks you for them, why should you spend time to publish them? But feel free to politely ask Bart of nu2.nu to publish his sources, to conserve the collected knowledge of BIOS compatibility tricks of ELTORITO.SYS and make people who want to tune or update this good old tool happy :-). Eric ------------------------------------------------------------------------------ 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
