I would like to implement a replacement MSCDEX driver (based on the replacement in FreeDOS SHSUCDX http://johnson.tmfc.net/freedos/shsucdx.html and SYSLINUX) however instead of talking to disk BIOS calls or PATA chipset I would like it to talk to the NDIS driver and act as a TFTP client simply forfulling application get block requests through TFTP. Its not clear where the ISO9660 CD filesystem is handled, maybe within the existing MSCDEX itself already and BIOS calls are used to get disk blocks from the CDROM unit. If possible I'd like to mimic A:, C:, D: (cdrom) supporting FAT, VFAT, ISO9660 backing images. Goemetry information and other meta data could also be obtained (maybe via TFTP too in a simple structured accompanying file to the backing image). I may even wish the TFTP client handle a media change event (triggered on another UDP port) so the TFTP client refreshes meta data and block requests and emits the same application errors as no CD in drive would. I wish to be able to run 1st and 2nd stage DOS installer programs seamlessly this way as well have have a "tftpdisk" that can present any ISO just as-if I had booted from an el-torio CD on the machine itself. Maybe somebody already knows of such a project or driver that already exists for this purpose ? Or maybe somebody can point out some floor in the idea ? It seems like 80% of the ground work is already done between the two projects. Thanks -- Darryl L. Miles
Darryl L. Miles wrote:> > I would like to implement a replacement MSCDEX driver (based on the > replacement in FreeDOS SHSUCDX > http://johnson.tmfc.net/freedos/shsucdx.html and SYSLINUX) however > instead of talking to disk BIOS calls or PATA chipset I would like it to > talk to the NDIS driver and act as a TFTP client simply forfulling > application get block requests through TFTP. >TFTP is not really the best choice for this. You'd want a network protocol which can support random access. MSCDEX, which uses the DOS "redirector" (installable filesystem) interface is not really the right thing to mimic if you want to mimic a floppy or hard disk (like MEMDISK); rather, you'd want to be a DOS block device, or even lower level -- mimic MEMDISK and talk to the PXE stack beneath an INT 13h interface. Any reason MEMDISK doesn't do what you need? -hpa
On 9/2/05, Darryl L. Miles <darryl at netbauds.net> wrote:> > I would like to implement a replacement MSCDEX driver (based on the > replacement in FreeDOS SHSUCDX > http://johnson.tmfc.net/freedos/shsucdx.html and SYSLINUX) however > instead of talking to disk BIOS calls or PATA chipset I would like it to > talk to the NDIS driver and act as a TFTP client simply forfulling > application get block requests through TFTP. > > > Its not clear where the ISO9660 CD filesystem is handled, maybe within > the existing MSCDEX itself already and BIOS calls are used to get disk > blocks from the CDROM unit. If possible I'd like to mimic A:, C:, D: > (cdrom) supporting FAT, VFAT, ISO9660 backing images. > > > Goemetry information and other meta data could also be obtained (maybe > via TFTP too in a simple structured accompanying file to the backing > image). I may even wish the TFTP client handle a media change event > (triggered on another UDP port) so the TFTP client refreshes meta data > and block requests and emits the same application errors as no CD in > drive would. > > > I wish to be able to run 1st and 2nd stage DOS installer programs > seamlessly this way as well have have a "tftpdisk" that can present any > ISO just as-if I had booted from an el-torio CD on the machine itself. > > > Maybe somebody already knows of such a project or driver that already > exists for this purpose ? > > Or maybe somebody can point out some floor in the idea ? It seems like > 80% of the ground work is already done between the two projects. > > Thanks > > > -- > Darryl L. Miles > > > _______________________________________________ > SYSLINUX mailing list > Submissions to SYSLINUX at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux > Please do not send private replies to mailing list traffic. > >Am I understanding you correctly to be saying that essentially you want a virtual cdrom using the network to get the cd image? I'm thinking that the cdrom extention driver isn't actually what you want for this purpose. I've seen utilities designed for fake cdroms in DOS and they never actually replaced mscdex/shsucdx, but, work along side it to create a false drive that could fool things. Mind you, their purpose was to fool games so they'd run fully off of the harddrive, and if you aren't meaning to use this for gaming, then you may not need something so complicated. Anyway, what I'm thinking is that you might want to speak with the author of fake cd, which you can find some info on here (email at bottom of page): http://www.math.uni-rostock.de/~nfa506/fakecddr.html It would probably make more sense to start from a basis of a software like that, then all you need to do is the networking instead of the entire thing.
Darryl L. Miles schreef:> I would like to implement a replacement MSCDEX driver (based on the > replacement in FreeDOS SHSUCDX > http://johnson.tmfc.net/freedos/shsucdx.html and SYSLINUX) however > instead of talking to disk BIOS calls or PATA chipset I would like it to > talk to the NDIS driver and act as a TFTP client simply forfulling > application get block requests through TFTP.as you probably know, original SHSUCDX package can be obtained from: http://www.geocities.com/jadoxa/shsucdx/ It contains SHSUCDX, a MSCDEX replacement. It also contains other programs, like an ISO mounting tool called SHSUCDHD. My private development version of FreeDOS is, from a diskette (with WGET on it), able to download the ISO file from the internet (any HTTP/FTP server actually) to harddisk or ramdisk, then mount it and continue from cdrom. Because the Memdisk imagefile we use (FDBOOT.IMG) has the same codebase as the diskette, it doesn't matter if you boot from any size of diskette, or boot the special 1.44MB diskette. This special diskette contains Syslinux, Memtest86+, Smartboot Manager as com32 module (allows using the Eltorito stack to continue booting from cdrom), the FreeDOS files directly runnable from disk to get access to cdrom, and the same files in a Memdisk image. The memdisk image means 'load 360KB one time, then execute from RAM instead of continuing to torture diskette by executing files from it'. My best guess is you use PXELINUX with a Memdisk image which contains MS Client combined with the UNDI driver. After that you connect to a share, which contains the ISO you want to use. Finally, use SHSUCDHD and SHSUCDX to obtain access to the contents of the cdrom. Please have a look at the following site for MS Client on 1 diskette: http://www.veder.com/nwdsk/index.html> blocks from the CDROM unit. If possible I'd like to mimic A:, C:, D: > (cdrom) supporting FAT, VFAT, ISO9660 backing images.Diskette mounting program can be found at: http://www.geocities.com/jadoxa/shsufdrv/index.html> I wish to be able to run 1st and 2nd stage DOS installer programs > seamlessly this way as well have have a "tftpdisk" that can present any > ISO just as-if I had booted from an el-torio CD on the machine itself.This procedure would only work for DOS. If you know an universal packet driver, then I would like to know about it. Booting a DOS diskette through PXELINUX/MEMDISK and using WGET is a lot easier than using MS Client. But MS Client has the advantage that files don't need a local copy, temporarily stored on the client machine on harddisk or ramdisk. I don't know about any ISO mounting tool that would allow to mount an ISO from the internet directly without first requiring you download the file. It's not common for disk mounting programs to use WATTCP32 :)> Maybe somebody already knows of such a project or driver that already > exists for this purpose ? > > Or maybe somebody can point out some floor in the idea ? It seems like > 80% of the ground work is already done between the two projects.I don't see PXELINUX loading a DOS ISO file to Client's RAM, then booting it through SmartBootManager's eltorito stack. Diskette download + ISO mounting is the way to go. However I'm not far enough with FreeDOS development to actually know how to dynamicly (on-the-fly) setup MS Client to access Samba shares. Bernd