Hi! > my point was that you won't have to provide a drive letter. ... > So that you could, say, debug your CONFIG.SYS not to load > SHSUCDX and/or ELTORITO.SYS?
I was thinking more of a config.sys menu item to load them while the others would be for normal boot without them... > 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, 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... The second, classic, method is using a bootable A: MEMDISK with all drivers on it, not limited to those for the CD/DVD inself :-). >> 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. Sure, see above ;-). Embedded files, built-in simple CD-ROM no-emulation drivers, all of that is certainly not trivial but sometimes fun to plan. >> 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. 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 ;-). >> 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. Compressing the kernel as if it were a DOS program works fine. The compressible part is first flattened (remove relocations) then a header for SYS CONFIG is added and 30-40 bytes of loader are added, configured to either SYS or EXE file format style of the compressible part. You need the header anyway, because boot sectors cannot load EXE files. Okay, big boot menus like GRUB can load complicated kernel file formats but the current style of "loader plus, optionally UPXed, exe" works perfect for DOS. Writing new tools or modifying UPX for only one single file will only annoy UPX developers or waste time of the new-tool-writers. > 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 :-). 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 :-). >> 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. >> 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 ;-). > >>> 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. >> 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". As said - try to implement it and then you will find out. 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 ;-). >>>>> Why is the source code (of eltorito.sys) not available? > Didn't "apparently few people" ask? Is that the same as "nobody"? I might be the only person who has asked yet. >> 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. 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
