Re: [Freedos-user] Re : Support for 4k byte sectors
Re: 4K sector sizes, I realized today that UIDE, UIDE2, and UIDEJR likely will NOT be affected at all -- 1) DOS has a 64K-byte limit for read/write requests, in fact 127 sectors of 512 bytes (the UIDE drivers do accept 128). Since 4K-byte sectors fit into this limit, no physical-level driver changes are needed. 2) All 3 UIDE drivers do ONLY physical block I-O and know nothing about directories, file systems, etc. The drivers remain DOS independent, i.e. they just read/write sectors at the orders of the DOS system and user programs. MUCH simpler and a LOT smaller! 3) UIDE/UIDE2 require, and UIDEJR can set, a 64K buffer in XMS memory for misaligned or other I-O unsuited to UltraDMA. Since DOS cannot do more than 64K I-O at a time, no change to the UIDE drivers' UltraDMA buffering is needed. 4) UIDE/UIDE2 set cache blocks of varying sizes, 8K for a 5-MB cache, up thru 64K for an 80-MB+ cache. So, the drivers have enough cache blocks in all cases to be effective, in handling both directory sectors and data files. 4K disk sectors fit evenly, into any UIDE/UIDE2 cache-block size same as 512-byte sectors do. So UIDE/UIDE2 will need NO changes for caching the larger disk sectors! About all that MAY be needed in the 3 UIDE drivers is some init logic to select using 4K-byte sectors, if a hard-disk demands this (FOOLISH if so, in my opinion!). Assuming boot or FDISK/FORMAT problems are dealt with as required, my comment about 4K-byte sectors is Bring 'em on! The 3 UIDE drivers will run fine with them and so regular DOS I-O should not be any problem! [In the U.S.A., we have an old engineering joke known as the K.I.S.S. Principle, whose letters denote Keep it SIMPLE, stupid!. Less and less of a JOKE, as time goes by and computers become unjustifiably COMPLEX! I and the UIDE drivers still OBEY the KISS Principle, insofar as is possible!]. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
Hi Bertho, trying to reiterate / re-explain my plan / idea: By the way - a DRIVER could interface with any disk with any sector size and then just provide an int13 or int25/26 interface with 512 byte sector size for data transfer to DOS. As explained in a longer mail this week, it actually SHOULD work: Only a few values in the boot sector would differ from a native 4k sector FAT filesystem compared to a filesystem where things work in groups of 8 sectors of 512 byte each, which is exactly what you would get when you make a 4k disk (containing a native 4k based FAT partition) visible as if it would have 512 byte sized sectors instead. This means you cannot make the RAW DISK visible to DOS that way, but you ONLY have to show DOS a modified boot sector to make the rest of an otherwise unchanged PARTITION work from native 4k sectors into show DOS 512 byte fake sec size. Because DOS only checks partition tables at boot, it never looks at a whole RAW DISK through block device drivers, not counting those built into the kernel for your boot drives. This means that it already is part of the normal job of any loadable block device driver to process partition tables and show sectors and boot sector properties to DOS. Software has routinely modified boot sector properties on the fly to show DOS tuned values for many years, e.g. for ramdisks etc. Note, however, that the OTHER way round is NOT compatible with other operating systems: You cannot FORMAT native 4k sector disks in a way that uses areas of 512 byte size as independent sectors and then show that disk to another OS as 4k sector disk. The disk must be already formatted with groups of 4k size in mind. Again, you CAN safely use 4k disks with 4k FAT partitions in a DOS with 512 byte sector size, as long as your block device driver converts the boot sector BPB properties on the fly into using 512 byte units. And as explained in my earlier mail, this ALWAYS works on FAT32 partitions with at most 2 TB size and at most 64 kB cluster size as limit. A block device driver for accessing native 4k disks with a fixed 512 byte per sector DOS kernel can easily show only those partitions which are not more than 2 TB, 64k-cluster. I mean my 15 Jan 2012 23:33 CET mail :-) This scheme won't work if the disk has to be usable aslo in other OSes like Windows XP, Linux, etc. that recognise the 4k sectors natively ! See above - disks partitioned and formatted in 4k compatible way or simply using the native 4k sector size can be used in all OSes in a compatible way, even in a 512 byte sector size with the help of a converted view on the boot sector block device driver in DOS which shows DOS each 4k sector as a row of 8 sectors of 512. They also STAY compatible that way, so DOS does not break anything by doing access in 512 byte units on the block device driver size. It only is a bit SLOWER, as the block device driver will still talk in 4k sectors when talking to that native 4k sector size disk. Someone, maybe not Eric, asked what I have been using for accessing USB mass storage in DOS. Answer : a version of Panasonic's USBASPI.SYS. This allows access to 4k sectors using SCSI commands. Interesting, but would that be easier than using Bret's or Georg's USB storage drivers? As long as somebody explains me how to write and read 4k sectors with those drivers, I should be able to show how to show 512 sectors and a transformed BPB on the DOS side, in that way making FAT32 partitions on that disk useable by unpatched FreeDOS with a simple loadable block device driver in a safe* way. *I cannot stop you from breaking the wonder by reformatting that partition in a non-4k-compatible way, apart from write-protecting the boot sector. You cannot repartition disks through block device drivers anyway, so THAT part is safe. Also, DOSFSCK will be happy (will not notice anything strange) and CHKDSK skips FAT32 anyway. Regards, Eric -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
Hi Bret, yes you would see a problematic mismatch if you were to talk raw SCSI or CHS to a disk while being inconsistent about whether you use 512 byte or rather 4096 bytes per sector... However, when DOS mounts a partition with help of a loadable block device driver, nothing would access the raw view of the disk. In any case the kernel will not, it will only talk to the block device driver. Anything beyond that is of course evil, but so is dosfsck-ing a partition in Linux while it is mounted at the same time. Can you recommend any free int 13 or block device based delayed / pooled write caching software? As far as I can remember, all modern (LBA compatible, given disk sizes on current PCs) implementations of this are commercial. ... This is why I suggest to first grow such a file to the final size, putting all FAT writes into ONE access and then writing the file's contents in large N kB chunks. Excellent idea, especially with USB. Thanks, but can you benchmark it? ;-) So you actually do the virtual trick the other way around? ... if a buffer is 2048 and the sectors are only 512, the last 1536 bytes of the buffer are simply never used. Ah, I had understood that you were showing a group of 4 native 512 byte sectors as if they were a 2k sector. Yes. But for reasons already discussed, this should not be done by virtualizing the sector size -- that is asking for problems, IMHO. Only if you can look beyond the virtualization in a bad way... For example the same issue existed with ontrack ezdrive drivers installed in the master boot record: When you booted a native-LBA-enabled operating system, the disk contents would appear shifted compared to the virtual LBA as seen while the driver is loaded... Only those versions of such drivers which tried to hide the space taken up by the driver suffered from the problem. In the suggested virtual 512 byte sector scenario, no shifting happens, BUT DOS is allowed to write in units of 512 bytes. Therefore, the virtual 512 byte sector block device driver must NOT allow DOS to re-format the partition because that would allow DOS to place things which have to be whole native 4k sectors at fractional locations. Also, DOS must NOT be allowed to repartition the disk, but that is easily done by not giving int 13 access to it. Block device drivers do not provide int13 anyway, so that one is easy? As long as DOS is not able to change partitioning or boot sector, the whole set of FAT32 structures will stay nicely aligned to 4k units. Apart from that, I still believe: Convert the BPB and boot sector on the fly, and DOS will be totally fine with looking at (and writing to!) a native 4k sector partition through looks like 512 glasses... :-) And of course it is nice that the magic values are just before the end of the first 512 bytes even when the native sector size is larger, makes things easy. Eric -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VirtualBox FreeDOS HowTo
I have started a VirtualBox HowTo in our FreeDOS wiki. It is a sort of installation walkthrough with many pictures. It can be found here: http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Installing_FreeDOS_in_VirtualBox That looks great, you've done an awesome job at posting such a detailed guide. I'm so happy I kept things simple for now so not that many issues will arise. [...] Thanks for your guide, I hope Jim will link it from the download page. I finally added this to the Download page. It looks great, thanks! -jh -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
yes you would see a problematic mismatch if you were to talk raw SCSI or CHS to a disk while being inconsistent about whether you use 512 byte or rather 4096 bytes per sector... That's precisely the problem. Depending on which DOS programs you use, some simply call DOS, some may use INT 25h/26h, some may use INT 13h, others may use raw SCSI/ASPI, and there are also other possibilities. If you could force all calls through the DOS device driver, you could eliminate any potential problems with DOS. But DOS doesn't force programs to do that, and there are certain kinds of programs (FDISK, FORMAT, SYS, CHKDSK, SCANDISK, ...) that require low-level access and can't go through the DOS Device Driver. And that doesn't even address the potential issues of using that same device on another OS or BIOS. The potential compatibility problems are just too great for me to even want to attempt this. FYI, my driver provides an INT 13h interface (and I think it's the only one that does). That allows you to use standard DOS utilities to partition and format and create bootable disks, without needing to resort (at least in some cases) to the special Windows and Linux utilities. However, when DOS mounts a partition with help of a loadable block device driver, nothing would access the raw view of the disk. In any case the kernel will not, it will only talk to the block device driver. Anything beyond that is of course evil, but so is dosfsck-ing a partition in Linux while it is mounted at the same time. It actually isn't evil in DOS to do low-level maintenance on a mounted partition. You just need to make sure you flush any buffers and caches, and re-mount if anything that DOS may care about (sector size, number of sectors, cluster size, ...) is changed. In the case of removable media (like USB and floppies), that shouldn't even require a reboot. Can you recommend any free int 13 or block device based delayed / pooled write caching software? As far as I can remember, all modern (LBA compatible, given disk sizes on current PCs) implementations of this are commercial. I don't know of any, but there's definitely a need for one. I normally don't use caches at all, but when I need one it needs to be a write-delay cache and I use MS SMARTDRV. I actually don't like SMARTDRV very much (it uses too much memory and requires a reboot to uninstall), but I have it and it works OK. I don't find write-through caches like LBACACHE and UIDE to provide enough speed benefit to be very helpful (though they might increase disk life to some degree). In addition, LBACACHE and UIDE are INT 13h caches instead of INT 21h caches (like SMARTDRV is), so they don't work with all disks (including USB and SCSI). When I really need to increase disk access speed (a big problem in some VM's), I copy my commonly-used utilities and batch files to a RAM disk. Thanks, but can you benchmark it? ;-) I've already done a simple benchmark, though I don't think it's exactly what you're looking for. It's discussed on pages 158 and 159 of USBINTRO.DOC (in the Sector Transfer Size discussion of the USBDRIVE section). Basically, the speed increases when you pool large numbers of contiguous sectors and send them at the same time. A true, valid benchmark would require all sorts of external parameter variability elimination, which I probably won't ever do. Only if you can look beyond the virtualization in a bad way... For example the same issue existed with ontrack ezdrive drivers installed in the master boot record: ... There are lots of examples of this in the past. I also remember when there were some programs that used incorrect formulas in the CHS - LBA translations that created all sorts of compatibility problems. That's why I think it's dangerous to do anything unique that no other OS or BIOS does. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
To set the record straight on caches and on UIDE -- Can you recommend any free int 13 or block device based delayed/ pooled write caching software? As far as I can remember, all modern (LBA compatible, given disk sizes on current PCs) implementations of this are commercial. I don't know of any, but there's definitely a need for one. I normally don't use caches at all, but when I need one it needs to be a write-delay cache and I use MS SMARTDRV. I actually don't like SMARTDRV very much (it uses too much memory and requires a reboot to uninstall), but I have it and it works OK. I agree with the above -- Write Back (delayed-write) caches usually are commercial, as they require a LOT of work and must be sold for a price. And I too absolutely HATED SMARTDRV -- Takes the most memory but caches the LEAST amount of data for it! I used Norton NCACHE2 for years, which is also a memory hog, but not as bad for the amount of data it handles. I don't find write-through caches like LBACACHE and UIDE to provide enough speed benefit to be very helpful (though they might increase disk life to some degree). In addition, LBACACHE and UIDE are INT 13h caches instead of INT 21h caches (like SMARTDRV is), so they don't work with all disks (including USB and SCSI). When I really need to increase disk access speed (a big problem in some VM's), I copy my commonly-used utilities and batch files to a RAM disk. No cache will ever compete with a RAM disk. RAM is always faster than disks with their seek/rotational latencies and their much slower transfer rates. But I dispute your comment about Write Through caches offering not-enough speed benefit, and I bet all VERY happy! users of UIDE might argue with you, as well. There is a REASON why Write Back caches are all so large -- they demand MANY hooks of a non-generic type into a DOS system, to handle Ctrl/Alt/ DEL and other events that require a flush of sectors not-yet written to disk. UIDE only needs to hook the Int 13h vector to do its functions. Also, UIDE is not just an Int 13h cache -- It CAN still be called by user drivers which desire its caching, though I am sadly aware that no one has ever done this. DOS driver development, or enhancement, isn't done that much any more. I did everything possible to make UIDE a FAST Write Through cache. It integrates caching with UltraDMA I-O for disks/CDs/DVDs; it can do direct UltraDMA to/from cache buffers to save time; it uses a binary-search when looking for cached data blocks (NOT hashing, which breaks-DOWN in speed at about a 35%-40% full search table); and it is only 5.2K (UIDE) or 4.5K (UIDE2) of assembly-language, as I REFUSE to have God-forsaken C in any SYSTEM driver as important as UIDE is!! But, if you wish to continue giving-up 40K+ for SMARTDRV, 80K+ for Norton NCACHE2 or however-many K for other Write Back schemes, feel free to do just that! I and others will continue using the 944-byte UIDE/UIDE2 and will be VERY happy! with the speed increase we DO get, from doing so! [And if there are still those who do not understand how UIDE/UIDE2 manage to require only 944 bytes of upper/DOS memory, just call it Sorcery!!]. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] questions on installation and acpi
Greetings, I wanted to try out FreeDOS on an old laptop where I have replaced the HDD with a CF card. I am looking to avoid floppies/CDs however, so I am wondering if anyone has an image that could be written to the CF card that would then boot into FreeDOS. I`ve found that once I have a bootable CF card I can dump the whole thing to an image using a sector editor, and use that image to make another CF card of equal or greater size bootable as well. Having a bootable image available would be convenient for some folks, am I right? I`m also wondering if it is possible to install FreeDOS onto a FAT16/32 partition alongside Windows NT4/2K/XP and add it to the Windows boot menu by pointing it to a file containing the FreeDOS boot sector. That is how I keep a win98 command prompt around as an option on 2K/XP boxes. The tricky part of course is getting that boot sector, along with the numbers in it that match the drive geometry. I`m assuming FreeDOS uses its own boot sector that is different than a DOS or win9x one, is this correct? Does it use IO.SYS and MSDOS.SYS as system files or are they called something else? The other thing I`m curious about is how speedstep and CPU states are working under FreeDOS. I have another laptop which had the CPU (a low-voltage one that is soldered to the board!) replaced with a faster model. Since the BIOS wasn`t designed to support this, it always boots up at the default (minimum) speed. There are utilities to manipulate the CPU speed under Windows but I haven`t found anything that runs under DOS. I tried FDAPM, and got an error about unable to parse ... but surprisingly, using the speed argument I was able to switch it to something even slower (but not faster). I didn`t know a Pentium M could run at less than 600MHz, but when I used speed4 it seemed like it was cut down to half that speed. (I took this opportunity to run the old bytemark CPU benchmark, which normally would crash on anything 600MHz or faster due to a bug) TIA... -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Bootable FreeDOS CD or USB Drive for Flashing Motherboard BIOS
Hi, I have an MSI brand motherboard which I need to flash to the latest BIOS. However, all my systems run Linux or *nix; I do not have a Microsoft Windows-based system for creating a bootable floppy. MSI seems to require a Windows or DOS-based operating system to do the BIOS flashing. Is there an easy way to do this with FreeDOS? I'd prefer to create a bootable CD that has the BIOS firmware file and *.exe flashing program right on it. I searched your Wiki and the freedos.org site for advice or an FAQ on this question. Help with this is deeply appreciated. Thanks Bob Cochran -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Bootable FreeDOS CD or USB Drive for Flashing Motherboard BIOS
Hi. Others have created a BIOS-flashing FreeDOS floppy, so I know it can be done. Might be easiest to create a bootable USB flash fob drive, and boot from that with your BIOS flashing software. Be aware that USB drives often get recognized on DOS as the c: drive, through legacy mapping. jh On Jan 16, 2012, at 9:51 PM, Bob Cochran bcochra...@verizon.net wrote: Hi, I have an MSI brand motherboard which I need to flash to the latest BIOS. However, all my systems run Linux or *nix; I do not have a Microsoft Windows-based system for creating a bootable floppy. MSI seems to require a Windows or DOS-based operating system to do the BIOS flashing. Is there an easy way to do this with FreeDOS? I'd prefer to create a bootable CD that has the BIOS firmware file and *.exe flashing program right on it. I searched your Wiki and the freedos.org site for advice or an FAQ on this question. Help with this is deeply appreciated. Thanks Bob Cochran -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Bootable FreeDOS CD or USB Drive for Flashing Motherboard BIOS
Hi, On Mon, Jan 16, 2012 at 9:51 PM, Bob Cochran bcochra...@verizon.net wrote: I have an MSI brand motherboard which I need to flash to the latest BIOS. However, all my systems run Linux or *nix; I do not have a Microsoft Windows-based system for creating a bootable floppy. MSI seems to require a Windows or DOS-based operating system to do the BIOS flashing. Is there an easy way to do this with FreeDOS? I'd prefer to create a bootable CD that has the BIOS firmware file and *.exe flashing program right on it. You can convert an existing bootable DOS floppy image into a .iso for burning to CD with the following (DOS) freeware tool: http://www.terabyteunlimited.com/downloads/mkbiso.zip And you can use the FreeDOS distribution and some kind of emulator (QEMU, VirtualBox, etc.) to format and sys a suitable (presumably 1.44 MB) floppy image. I searched your Wiki and the freedos.org site for advice or an FAQ on this question. Help with this is deeply appreciated. If the above isn't obvious enough, I can be more detailed. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Bootable FreeDOS CD or USB Drive for Flashing Motherboard BIOS
On Mon, 16 Jan 2012 22:51:36 -0500, Bob Cochran bcochra...@verizon.net wrote: Hi, I have an MSI brand motherboard which I need to flash to the latest BIOS. However, all my systems run Linux or *nix; I do not have a Microsoft Windows-based system for creating a bootable floppy. MSI seems to require a Windows or DOS-based operating system to do the BIOS flashing. Is there an easy way to do this with FreeDOS? I'd prefer to create a bootable CD that has the BIOS firmware file and *.exe flashing program right on it. I searched your Wiki and the freedos.org site for advice or an FAQ on this question. Help with this is deeply appreciated. Thanks Bob Cochran Check whether your MSI motherboard BIOS supports booting from LAN, a.k.a. PXE. If so, then you can insert the BIOS update into a bootable disk image (using winimage or similar) and make it available via TFTP from another PC on the LAN. Then when you power on the MSI system it can grab the disk image over the network and boot it as if it were a physical floppy. More details here: http://www.devshed.com/c/a/Administration/Network-Booting-via-PXE-the-Basics/2/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
