> 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.


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

Reply via email to