Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
Hi! 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. 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... But if you do really ask me, all this is getting much too complicated and you should just use MEMDISK with the files really there in a real drive (well as real as MEMDISK can get) so you have full flexibility and avoid the need to use exotic tools to create the disk image at exotic locations and avoid kernel changes. 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 before doing the UPX and header messing, also making the latter more advanced to know file sizes and offset etc. But as said, I prefer not to put raw files in the kernel at all. 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. 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. 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 ;-). 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.) Which is why I recommend non-embedded disk images with MEMDISK. The tools used to edit those are included in every Linux and easy to get for Windows users. No new tools would be needed. 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? 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 :-). 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
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, 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.) 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 ;-) 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. 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. or waste time of the new-tool-writers. Don't we waste time anyway? 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 :-). Yes, but that appends only one file. Appending two files to the kernel raises the need to find where the second file begins. (If possible without unreliable signature searchs.) 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? 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. You load these files once. I see no need to create a filesystem through which you could access these after booting. 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 ;-). 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.) 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. 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. Despite this, DEVICE= is executed during CONFIG time instead of pre-CONFIG. 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 ;-). In DOS no problem is normal ;-) But feel free to politely ask Bart of nu2.nu
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
Yes, but that appends only one file. Appending two files to the kernel raises the need to find where the second file begins. (If possible without unreliable signature searchs.) using the SYS CONFIG mechanism, you could easily have SYS CONFIG /AndThe1stAttachedFileIsHasSize12345 /AndThe2nd... doesn't solve the problem that SHSUCDX is a .COM/.EXE file running those at config.sys time presents real problems. feasible, not without some sweat and tears 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? if you can't create such a tool easily, I recommend Java, Visual Basic, or Playstation III as computing platform. not even worth talking about. Just do it. if it's useful, tell us about it. but don't talk, talk, talk about it. Tom -- 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
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. 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
Hope you don't mind me to ask, why didn't you rather contribute to FreeDOS? First, I do sometimes contribute to FreeDOS (i.e. DEVLOAD) and sometimes even to the thing called FreeDOS kernel (or DOS-C), which is to be distinguished from FreeDOS as a project. However I choosed not to become a developer of DOS-C (FreeDOS kernel) because it's design is to be written in C where possible which I think is a bad decision (Japheth probably agrees here). Besides, I'm too egoistic to write or re-write major parts of something when this new version isn't accepted because it isn't tested enough. That was the case with the unstable DOS-C version 2037 (which had many features version 2036 and the upcoming 2038 don't have). But he DOES contribute to FreeDOS: Who is he?? Me. once the few remaining bugs are fixed in the RxDOS kernel, it will replace the inferior current FD kernel. That's a nice point of view but you'll have to wait until it's done. To speak about few remaining bugs doesn't match the reality. Another caveat is that once might have to wait another few months or year. I tested a lot RxDOS and was very frustrated becuse: 1) it was very good and very compatible Doesn't match my experience. (Well, you probably tested it another way as I did.) 2) it had very few bugd (iirc only 3) 3) the bugs were *very* bad, I just don't remember exactly but completely incapacitating Yes they're quite some bad bugs. Some of these are in RxDOS's COMMAND.COM replacement RxDOSCMD (or, as I call it now, RxCMD) which I will probably fix too. 4) the programer was the author of Undocumented DOS Michael Podanoffsky, the best book around, but he just vanished (abandoned?) Errm, nope. I think Mike did contribute to Undocumented DOS (you can ask him by e-mail), but his own book was Dissected DOS. It concentrates on the RxDOS 6.00 source instead of showing disassembled MS-DOS code. Of course I've both books on hand here. 5) it was just MS-DOS 6.22, and now FreeDOS has many important things, one being FAT32 which I cannot live without. True for RxDOS 6.00 (shown in Dissecting DOS) but not for RxDOS 7.x. The newer RxDOS releases have FAT32 (just as DOS-C) plus LFN functions *inside the kernel*. That is you shouldn't need DOSLFN to use LFNs. However both features will often not work as expected because they're slightly buggy and incompatible. One of my goals is to improve this. 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
Hope you don't mind me to ask, why didn't you rather contribute to FreeDOS? But he DOES contribute to FreeDOS: once the few remaining bugs are fixed in the RxDOS kernel, it will replace the inferior current FD kernel. why do you think that the RxDOS kernel is superior - besides having many more bugs ? Tom -- 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
First, I do sometimes contribute to FreeDOS (i.e. DEVLOAD) and sometimes even to the thing called FreeDOS kernel (or DOS-C), which is to be distinguished from FreeDOS as a project. However I choosed not to become a developer of DOS-C (FreeDOS kernel) because it's design is to be written in C where possible which I think is a bad decision (Japheth probably agrees here). Japteth didn't any Freedos kernel programming. And Tom *fullheartily* disagrees here. Besides, I'm too egoistic to write or re-write major parts of something when this new version isn't accepted because it isn't tested enough. That was the case with the unstable DOS-C version 2037 this entire bullshit. 2037 has been tested, and the reults say 'unstable' 2037 had some very welcome enhancements (country.sys support comes to my mind, but there may be more). unfortunately 2037 has also a zillion of Arkady's 'optimizations'. at least one of them made the kernel unstable. not unstable as in 'linux kernel with an odd number', but unstable as in 'do not use for production. will sometimes suprise you' in that case, Jeremy is to blame, as he merged Arkadys optimizations, but never took the time to backtrace them to a to be tested, but stable 2037. feel free to re-add country.sys support to 2038 (which had many features version 2036 and the upcoming 2038 don't have). yes, sadly. once the few remaining bugs are fixed in the RxDOS kernel, it will replace the inferior current FD kernel. That's a nice point of view but you'll have to wait until it's done. To speak about few remaining bugs doesn't match the reality. this might be the reason DOS-C was chosen instead of RxDOS. the other might be simple availability. at least the FreeDOS kernel in 2001 was buggy like hell. Mit freundlichen Grüßen/Kind regards Tom Ehlert +49-241-79886 -- 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
That was the case with the unstable DOS-C version 2037 (which had many features version 2036 and the upcoming 2038 don't have). I forgot to mention: 2038 is 'upcoming' since about 2 years. it's probable stable (the last changes were done by Bart, no Arkady in sight ), most likely better then 2036 (at some bugs fixed), but still not published. similar can be said about 'Freeedos 1.1 forever' Tom -- 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
also many things are running in background :) just ask Eric, Mateusz, Rugxulo, Blair, ... That's probably one of FreeDOS's problems: there's ony guy - I don't want to be more specific - who forces all communication into private mails. This makes the current FD status absolutely intransparent for other people. The public mailing lists - kernel and devel - are either virtually empty and dead or filled with lot of noise. -- 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
why do you think that the RxDOS kernel is superior - besides having many more bugs ? What about built-in support for LFN? -- 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
Hi Geraldo, uhm, i can't say that much once i'm just a newbie, but on kernel side would be possible to track all those 'bad' changes? Please use the new kernel 2037 thread for this :-) btw, Arkady, are you there? I hope so :-) maybe you can comment out it, please note, i'm not saying it to create a flamewar but instead say: 'hey guys, some people disagree with some patches, okay! let's review it and try to make everybody happy, or at least most people...' what do you all think? See the other thread - some patches are useful and easy, others useful and complicated, some are maybe only very complicated but of little use. Review can still help... i think this a nice way to make things happen, ok, we can get stalled as gnu hurd, but we already have a functional replacement for dos, so THAT IS FINE! Yeah but only the unstable branch is stalled right now ;-) on freedos 1.1, ehehehe i'm working on packages, i still pending the list because i got busy with some other stuff at my job Indeed, a list of already done versus still to do things would help others to take over part of your work... ;-) but really i think we are going to make fd 1.1 until this year, that is for sure(at least from my part) also many things are running in background :) just ask Eric, Mateusz, Rugxulo, Blair, ... See Ya! Have a nice weekend :-) 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
Hi! Well theoretically you can write a DOS CD no-emulation boot sector. Finding the sector numbers of a file in a root directory of ISO9660 for read-only access cannot be that hard ;-). But of course all this does not make much difference because you have no ISO9660 in kernel and would be unable to access any other files next. while combined EXE-SYS can even be UPXed with newer UPX. The interesting thing is that you can have TWO different entry points. The EXE one is defined in the exe header, while the SYS one is defined in a sys header which is at the beginning of the LOADED part of the exe file :-). And as said, you can even UPX in a way that leaves both entry points useable, just by using a modern UPX version. For example HIMEM(X) and (J)EMM386 are EXE-SYS files. 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
Christian Masloch schrieb: Note that this would mean that you have to find the sources of ELTORITO.SYS - nu2.nu says it is now free / unmaintained but sources are not yet public - and add ELTORITO and also SHSUCDX into the kernel itself. Otherwise you will be able to boot the kernel, but will not be able to load any other file from CD/DVD [...] As I said CD no-emulation booting support requires GRUB4DOS or some other boot loader anyway. So why bother? PS: Comment on your other binary formats, combined COM-SYS is evil Well, it turns out to work. If it doesn't on some DOS I can come up with missing MS-DOS compatibility. (It would only affect the driver loading anyway, the executable would still work.) while combined EXE-SYS can even be UPXed with newer UPX. But you can't combine EXE-SYS-FlatKernel, because stuffing code and the MZ header into the same file location is (I assume) impossible. (And thinking about how to make kernels (!) compatible with UPX probably isn't that important. Better write some new utility that compresses selected parts of the kernel and customize it for each kernel, instead of customizing each kernel for some or another UPX hack.) However, for a kernel, neither DEVICE nor DOS executable file format make much sense... You already say that the only thing done by RxDOS when loaded that way is showing some message ;-) This might change. Renaming the kernel file to RXDOS.COM, the executable part could load some other part of the executable (probably behind the image required to boot the kernel*) containing a program for configuration or status display. This would be quite useful because it could (after aborting if the kernel version found in the file isn't running) contain things very specific to the kernel version. Because the file would be needed to boot the kernel anyway, it would usually be accessible and couldn't be confused with another version (which would abort on another version of the kernel). YES it is spelled RxDOS with a small letter x ;-) * Currently limited to 64 KiB in size, but could be increased to 128 KiB. Christian Hope you don't mind me to ask, why didn't you rather contribute to FreeDOS? -mr -- 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
Hi :-) No-emulation boot with FreeDOS and without memdisk would be cool. Maybe. But MEMDISK works fine, too. Is it possible to inject eltorito.sys and shsucdx into the kernel? You would need eltorito.sys source code first, and have to be aware that shsucdx is about 8 kB (6 kB UPXed, 6 kB or more in RAM depending on how you load it). All this would have to fit (preferably) into the resident-in-HMA part of the kernel, which is about 40 kB now: The rest of the 64 kB HMA is used for BUFFERS. If you do not have enough HMA space left, you have to put BUFFERS in low RAM. Eltorito.sys itself is quite small afair, maybe 2 kB...? That would probably be less efficient than putting the CD drivers there... In addition, having ELTORITO and SHSUCDX in the kernel will mean that you cannot use the driver in other situations than booting from CD/DVD. If you want to use CD/DVD in other situations, you have to load a normal SHSUCDX later, basically spending the RAM for it twice. And of course: CD/DVD infrastructure in kernel means that you have no or at least no reasonably useful cache for it. In short: A very exotic situation :-). Linux also has many drivers in separate files (loadable modules) and puts them into a boot ramdisk, as this gives more flexibility and less wasted space compared to having them all in the main kernel binary - which is possible there, too, but only for people who really want to hand-tune their system a lot ;-). Some other ideas: - a simplified read-only, 8.3 filename, no-subdirectory eltorito boot CD/DVD driver would already be enough to let DOS load further drivers for full CD/DVD access... - a special boot ramdisk could be added to the kernel binary before compressing it. kernel code could access it, say, as B: drive, using the already built-in FAT drivers... The latter idea is useful when you have a boot sector that can load ONE file. For example a CD/DVD boot sector which is able to load the kernel via eltorito :-). The former idea probably adds more complexity to the kernel than the latter idea, but is easier to use. The latter idea would need extra tools to create the boot ramdisk, but you will not need full recompiles to modify the ramdisk contents. 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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
Hope you don't mind me to ask, why didn't you rather contribute to FreeDOS? But he DOES contribute to FreeDOS: once the few remaining bugs are fixed in the RxDOS kernel, it will replace the inferior current FD kernel. -- 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
