Hi, >> 1. Add very basic readonly root directory file >> read ability for ISO9660 CD/DVD to the kernel, > > However this requires major code re-writing for this new driver, instead > of relying on working drivers. (Which only requires the kernel to have > this drivers's files embedded or on a boot disk image.)
...embedded requires major code re-writing for this new kernel, instead of relying on working FAT drive support (which only requires the kernel to access a boot time ramdisk, typically some int 13 based ramdisk). But files in a boot disk image are nice, yes :-). >> 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... > > Well, just add support for the well known drive letters [\]^_` > into the kernel and that's it ;-) We already have SOME 32 drive awareness, but as I did not know that they are called [ \ ] ^ _ ' I never tested them. Nor do I know whether our command.com etc would allow me to type them. Maybe you can do some experiments and find out which parts need adjustment. Note that \ should not be used, conflict with UNC. >> 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 ;-). > > Sounds fun but isn't really reliable. Another ELTORITO.SYS version could > easily include such a "misleading" MZ. Future versions of SHSUCDX (you > said 6 KiB?) could easily be assembled into a .COM executable as well. Yes. Just thinking aloud ;-) >> Writing new tools or modifying UPX for only one single file will >> only annoy UPX developers > > You could release it as fork (or patch) if they don't want to include it > in their distribution. No thanks. >> or waste time of the new-tool-writers. > > Don't we waste time anyway? Yes, but the topic is too much fun to talk about ;-) >> 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 :-). > > Is it complex compared to the message file creator or complex compared to > other compile environments? You basically have a textfile with messages and then run 1-2 commands like "makemessagelibrary in.txt out.xyz" and maybe "compressmessages in.xyz out.abc", I do not remember exactly. As said, for already existing translations, you simply COPY two already existing files together to have a command.com in one of the already supported languages of your choice :-). > You load these files once. I see no need to create a filesystem > through which you could access these after booting. That is true, yet you cannot load them before the kernel, only from within the kernel, complicating things. Those CD/DVD drivers are not as easy to use as TrueCrypt ;-). >> Well you can spend your own time on the project but do not >> complain if it takes long or introduces new problems ;-). > > If it introduces problems they'll often be solutions for these problems as > well. (Or you just avoid problems, which isn't difficult at boot time > because you don't have to be MS-DOS compatible then.) As said - depends on how much time you want to spend. And you do have to be compatible at the moment when you start loading drivers in config.sys, some other data structures even have to be filled in earlier than that. > Well, "being DOS" doesn't seem to include "organizing memory in a chain of > MCBs as DOS" in MS-DOS pre-CONFIG/CONFIG time. As shown by the recent > tests with Debug there is only one MCB containing all low memory. If it's > the same in DOS-C (I doubt it is) SHSUCDX couldn't load. Exactly - running EXE/COM files is not possible before the INSTALL and SHELL phase, while running SYS files is usually done earlier. Tools like DEVLOAD can run SYS files later, at the cost of having to "repair" some structures and not being able to load "early" drivers as HIMEM / EMM386 fully: You can DEVLOAD them but DOS ignores some features then. > Despite this, DEVICE= is executed during CONFIG time instead of pre-CONFIG. ...strictly before INSTALL, yes. > In DOS no problem is normal ;-) ;-) 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
