>>> 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).
I think accessing file contents from RAM is easier than writing a small ISO 9660 driver. >> 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. Note that the last is not ' (single quote) but ` (some sort of accent). Just look at ASCII character set listings, they show these characters right behind the capital letters. > Nor do I > know whether our command.com etc would allow me to type them. Yes, application software usually has to be aware of these drive "letters". (Displaying the drive might still work if the application just gets the drive number and adds the value for ASCII 'A'.) > Maybe you can do some experiments and find out which parts need > adjustment. Note that \ should not be used, conflict with UNC. No. If you're accessing something that starts with "\:", the backslash is clearly used as drive letter. >>> 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 ;-) I see your point :-) >>> 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. No, I meant "is the compile environment needed to compile command.com more complex than compile environments needed for other (DOS) software?" >>> 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. Yes, but the first relocation of the kernel data and code is done when there's no CONFIG and DOS isn't even available. So it doesn't have to be compatible. >> 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, That's how it might be currently. However I think you could change the pre-INSTALL phase to be compatible enough for executing SHSUCDX, while still being compatible to MS-DOS device drivers later. > while running SYS files is usually > done earlier. Tools like DEVLOAD can run SYS files later, > at the cost of having to "repair" "patch", "extend"? > some structures and not > being able to load "early" drivers as HIMEM / EMM386 fully: > You can DEVLOAD them but DOS ignores some features then. If you knew the location where DOS stores the first UMB's address and such stuff you could later patch DOS to add UMBs; which you've allocated from the XMS driver of course. (I think MS-DOS 5.00+ stores this data in the "buffer info record" which is pointed to by a List of Lists entry, see RBIL Int21.52.) Moving the DOS code to the HMA is of course more complicated. (Read: I don't know how to do this in MS-DOS.) 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
