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.sourcefor
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
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 __
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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
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
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
>> 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. Of course, but my point was that you won't have to provide a drive letter. > 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... So that you could, say, debug your CONFIG.SYS not to load SHSUCDX and/or ELTORITO.SYS? Why? After all, it would be a special kernel binary used to boot CD-ROMs only, so you would usually want to load both. > 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. >> 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 The kernel then had to know file1's and file2's size which is no usable solution. > 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. 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? > also making > the latter more advanced to know file sizes and offset > etc. Yes, to make it more of a bad hack? Or do you want to write a linker? > But as said, I prefer not to put raw files in the > kernel at all. C design limitation? ;-) >>> 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. 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. >> 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. (In fact, as with the "S" MCB allocation, a post-CONFIG compatible DOS might make things easier for the CONFIG.SYS parser.) >> 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 ;-). Of course the great DOS-C development strategy would be to split all developers in two branches here, one "mainstream" and one "interesting". 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? Didn't "apparently few people" ask? Is that the same as "nobody"? > 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 :-). I'll do so if I ever want to boot from a CD-ROM in no-emulation mode. 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/li
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
> 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
Hi, >>> 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... > You could just add both binaries to the kernel binary, then > let the CONFIG.SYS parser/init code load them if desired. 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) as well as extra tools to generate such a "kernel with diskimage" combined file in the first place. Note that our boot sector already can boot > 64k kernels. 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. > 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 :-) > BTW, the driver's size is 1.5 KiB with UPX > compression, 4 KiB without. Yes, it is really small. But it contains workarounds for a number of known BIOS bugs, so the source code would be a valuable reference if it explains the bugs and their workarounds, even if vaguely. If the source code comments are written in another language than English: No problem, I am sure we can translate them :-)). Eric PS: When browsing grub4dos sources, I noticed that the list of known BIOS bugs has: 1. LBA write support missing for CD/DVD boot, 2. int 15.87 RAM access support missing (this can hurt HIMEM, FDAPM, unless cured by EMM386??), 3. int 15.24 A20 support missing 4. int 13.08 geometry can be wrong on CD/DVD/USB boot, 5. CD/DVD boot sometimes loads only 1 sector in no-emul, to mention my top five. -- 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
>> 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...? > > [...] You could just add both binaries to the kernel binary, then let the CONFIG.SYS parser/init code load them if desired. This would only require a larger kernel file (and more sophisticated boot loading code to cope with >64 KiB) but no modifications of SHSUCDX and that El Torito driver. Why is the source code not available? If you'd really need it badly someone could disassemble it. BTW, the driver's size is 1.5 KiB with UPX compression, 4 KiB without. 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 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
> 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
> 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
Hi guys, 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? btw, Arkady, are you there? 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? 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!!!(at least imho) people always come and go, community stills alive, this is not the first time we got stalled and as a answer comes, just take fd 1.0 release... we are in the situation imho, maybe we had more people helping but it still not stopped us to release it... on freedos 1.1, ehehehe i'm working on packages, i still peding the list because i got busy with some other stuff at my job 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! Geraldo Sapere Aude Non ducor, duco São Paulo, Brasil, -3gmt site: http://exdev.sf.net/ msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 2009/2/7 Tom Ehlert : > > > >> 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 > -- 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
> 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
>> 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
>>> 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
Hi all, I was following this not too closely, but suddenly it caught my attention and I could find nothing im my deletted messages. Can someone *please* help me with my memory Japheth escreveu: >> Hope you don't mind me to ask, why didn't you rather contribute to FreeDOS? > But he DOES contribute to FreeDOS: Who is "he"?? > once the few remaining bugs are fixed in > the RxDOS kernel, it will replace the inferior current FD kernel. I tested a lot RxDOS and was very frustrated becuse: 1) it was very good and very compatible 2) it had very few bugd (iirc only 3) 3) the bugs were *very* bad, I just don't remember exactly but completely incapacitating 4) the programer was the author of "Undocumented DOS" Michael Podanoffsky, the best book around, but he just vanished (abandoned?) 5) it was just MS-DOS 6.22, and now FreeDOS has many important things, one being FAT32 which I cannot live without. 6) I believe that most FreeDOS utils will run, but not all Anyway, it is nice to know that someone is working on it Alain -- 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
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
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
Eric Auer schrieb: > Hi, > >> "grub4dos without menu" as "generic" boot file for FreeDOS >> is really unnecessary, unless you need CD-ROM no-emulation >> boot support or a file of which only the first few sectors >> are loaded. I'm sure someone writing Assembly and motivated >> enough could add the described generic boot support to the >> DOS-C (FreeDOS) file KERNEL.SYS itself. > > 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, not even config.sys ;-). My personal idea > of the situation is that booting from a virtual floppy via > CD/DVD is a well-working and tested workaround, either with > BIOS 1.2 / 1.44 / 2.88 MB floppy image or with MEMDISK any- > size (even compressed) floppy image loaded from GRUB4DOS or > ISOLINUX in no-emulation mode. Only no-emulation mode lets > you enjoy ELTORITO.SYS access, but remember that free SATA > and IDE/ATAPI CD/DVD drivers for DOS already exist, such as > GCDROM, XGCDROM, XCDROM, UIDE and possibly others :-). > > Eric No-emulation boot with FreeDOS and without memdisk would be cool. Is it possible somehow to inject eltorito.sys and shsucdx into the kernel? -mr > > > > PS: Comment on your other binary formats, combined COM-SYS is > evil while combined EXE-SYS can even be UPXed with newer UPX. > 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 ;-) > > > > > -- > 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 > > -- 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
> 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 -- 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, > "grub4dos without menu" as "generic" boot file for FreeDOS > is really unnecessary, unless you need CD-ROM no-emulation > boot support or a file of which only the first few sectors > are loaded. I'm sure someone writing Assembly and motivated > enough could add the described generic boot support to the > DOS-C (FreeDOS) file KERNEL.SYS itself. 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, not even config.sys ;-). My personal idea of the situation is that booting from a virtual floppy via CD/DVD is a well-working and tested workaround, either with BIOS 1.2 / 1.44 / 2.88 MB floppy image or with MEMDISK any- size (even compressed) floppy image loaded from GRUB4DOS or ISOLINUX in no-emulation mode. Only no-emulation mode lets you enjoy ELTORITO.SYS access, but remember that free SATA and IDE/ATAPI CD/DVD drivers for DOS already exist, such as GCDROM, XGCDROM, XCDROM, UIDE and possibly others :-). Eric PS: Comment on your other binary formats, combined COM-SYS is evil while combined EXE-SYS can even be UPXed with newer UPX. 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 ;-) -- 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
The first 512 byte (usual sector size) of my in-development RXDOS.SYS file contain code so that it's a valid DOS executable (.COM of course), DOS device driver (try DEVICE=KERNEL.SYS), DOS kernel, and GRUB4DOS (probably normal GRUB as well) chainloadable without special support as for KERNEL.SYS (required: 0AA55h signature at address 510, code segment fixup by jumping from 0:7C00h to 7C0h:0). It can also be loaded by DR-DOS LOADER, though LOADER always sets dx to zero so the default binary would always attempt to read CONFIG.SYS from drive A:. By forcing a boot drive value at "compile" time, a special LOADER binary can be created that always reads CONFIG.SYS from the first partition of the first hard drive (the only one LOADER seems to support anyway). The DOS executable and DOS device driver entries don't contain actual programs, they just abort displaying a message stating that this is the wrong way to use the binary. The DOS kernel entry, which is the default, is loadable at almost any low memory segment (50h til end of memory less two times the file's size) but requires offset zero. The default binary expects dl to contain the BIOS boot drive number but as mentioned a special binary with forced drive is created with some assembler options. Of course all of this is done in real mode Assembly. Requesting a "grub4dos without menu" as "generic" boot file for FreeDOS is really unnecessary, unless you need CD-ROM no-emulation boot support or a file of which only the first few sectors are loaded. I'm sure someone writing Assembly and motivated enough could add the described generic boot support to the DOS-C file KERNEL.SYS itself. (If someone is interested I can send the related source.) The only major problem is that SYS CONFIG currently expects it's data block at a fixed address in the binary, which is not available with the described code because the DOS device header is to be placed there. Also, you can't compress generic bootable files just by hacking parts of the UPX loader as currently done for DOS-C (and the EDR-DOS kernel). 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! I assume ms-sys on Linux is something like sys-freedos-linux (sys-freedos.pl) and makebootfat and bootlace, but for MS DOS? What is the license, where can you find it, how flexible is it? > GRUB4DOS can load the FreeDOS kernel.sys directly. I have used > it to do so on USB drives. > Another option would be just using ms-sys on Linux with the -p4 > or -p5 switches (depending on if the volume is FAT16 or FAT32.) As there was so much talk about how "generic" GRUB4DOS can be, I checked the internet and found some very interesting infos on: grub4dos.sourceforge.net/wiki/index.php/Grub4dos_tutorial and svn.gna.org/svn/grub4dos/trunk/README_GRUB4DOS.txt my notes are: GRLDR can be loaded by MBR, boot sector, NT family boot menu boot.ini (boot sector?) file and as eltorito boot file (!). GRUB.EXE can be loaded from the DOS prompt AND as a DOS device but also as if it were a Linux kernel file. GRLDR.MBR can be loaded as boot.ini as if it were a boot sector: It can scan FATnn/EXTn/NTFS partitions for GRLDR files and load the 1st but seems to prefer non-NTFS and active/bootable primary partitions. NOTE: MS DOS DEVICE allows 4k long command line options, interesting! mkisofs -R -b grldr -no-emul-boot -boot-load-seg 0x1000 -o X.iso /Y/ loads the whole grldr, but some bioses only load the first 2k, bad mkisofs -R -b grldr -no-emul-boot -boot-load-size 4 -o grldr.iso /Y/ loads only one sector NOTE: No-emulation-mode means the CD/DVD will be accessible via int 13, and GRUB scans all drives 80-ff for such CD/DVD items. You can even boot GRLDR via PXE over the network... http://grub4dos.sourceforge.net/wiki/index.php/Grub4dos_tutorial The filename GRLDR shouldn't be changed. If GRLDR is in a NTFS partition, it should be copied to the root directory of another non-NTFS partition(and likewise should the menu.lst file be). ...BIOS drive number must be passed in CPU register DL... Boot Record Layout(s) for EXT2, EXT3, FAT1x, FAT32, NTFS etc are explained on the README_GRUB4DOS page, too... :-) NOTE: Offset 2 must be 90 for CHS, 0e for LBA, Win9x needs it. The bootstrap code of GRLDR.MBR only finds GRLDR file in the root dir of a partition. While the startup code of grldr might fail to load GRLDR in NTFS partitions, it always successfully loads GRLDR in FAT partitions (and even in ext2/ext3 partitions). "Note that NTLDR only loads the startup code of grldr (i.e., the leading 16 sectors of grldr), not the whole grldr file." > binary file main source file other files > grldrgrldrstart.S pre_stage2(binary) > grldr.mbrmbrstart.Sgrldrstart.S > grub.exe dosstart.Spre_stage2(binary) (pre_stage2 is the main body of GNU GRUB... it also copies a backup of the first 640k to 2 MB, and restores it to let you return from GRUB to DOS without booting another OS...) http://svn.gna.org/svn/grub4dos/trunk/README_GRUB4DOS.txt NOTE: GRLDR (as a no-emulation-mode bootable CDROM image) was adapted to cope with some buggy BIOSes (e.g. VirtualPC). LBA-to-CHS geometry translation was added in int13_handler to simulate LBA (EBIOS) on CHS-only drives http://osdir.com/ml/linux.freshmeat.announce/2007-01/msg0.html ... so you have: GRLDR - header useable as MBR, normal or ElTorito boot sector. Scans for GRLDR file to load rest of itself. GRLDR.MBR is the same, but only the first sector of it, I would say... GRUB.EXE - loadable as DOS EXE, DOS DEVICE and Linux kernel I probably forgot some other magic boot methods :-) 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
