>> 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.
Of course, but my point was that you won't have to provide a drive letter. > 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... So that you could, say, debug your CONFIG.SYS not to load SHSUCDX and/or ELTORITO.SYS? Why? After all, it would be a special kernel binary used to boot CD-ROMs only, so you would usually want to load both. > But if you do really ask me, all this is getting much > too complicated [...] Yes. That's the reason I suggested not to build CD-ROM no-emulation boot support into the kernel. Well it's still interesting to think about the possibilities. >> 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 The kernel then had to know file1's and file2's size which is no usable solution. > before doing the UPX and header messing, Rather stop messing with headers and UPX and create a new compression tool (or UPX binary format) for the kernel. 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? > also making > the latter more advanced to know file sizes and offset > etc. Yes, to make it more of a bad hack? Or do you want to write a linker? > But as said, I prefer not to put raw files in the > kernel at all. C design limitation? ;-) >>> 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. 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. >> 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. (In fact, as with the "S" MCB allocation, a post-CONFIG compatible DOS might make things easier for the CONFIG.SYS parser.) >> 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 ;-). Of course the great DOS-C development strategy would be to split all developers in two branches here, one "mainstream" and one "interesting". >>>> 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? Didn't "apparently few people" ask? Is that the same as "nobody"? > 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 :-). I'll do so if I ever want to boot from a CD-ROM in no-emulation mode. 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
