I recently made a floppy that boots MS-DOS 6.22. It boots successfully, but then I can't access the hard drive. It can access the floppy drive and CD optical drive, but not the hard disk.
I first tried making a floppy by downloading from www.allbootdisks.com. Then I tried making a floppy from bootdisk.com. Both have the same problem.
What should I do to access the hard disk? Do I need a driver?
From your comments:
"It has its own drive letter (F:)"
...actually drive letter config is specific to instance of the O/S you're running under. A partition does not have an intrinsic drive letter. That may be the letter your disk is mapped to in Windows, but it doesn't mean anything outside that context. Under Linux for instance, the same partition would be mapped an entirely different way, because Linux has no no concept of drive letters. Equally if you have two versions of Windows installed on a PC you could have the same physical partition mapped as F: on one install and G: on another.
So under DOS your partition is not necessarily mapped to the same (or any letter). According to https://en.wikipedia.org/wiki/Drive_letter_assignment#Order_of_assignment it will map each readable partition automatically in the order it detects it. So it might be C: or D:, maybe. So you need to check and see if it's been mapped to another letter.
Of course it's also possible it may not actually detect the disk at all. Drives installed via SCSI or SATA will probably require extra drivers. You may have a hard time finding a SATA driver in particular, since this technology didn't exist when MS-DOS was current. If your BIOS supports it, try putting the disk into IDE emulation mode and hopefully DOS can then detect it. You may lose a bit of performance, but at least you can access the disk.
Related
I wonder how windows distinguishes between diferrent drives and memory modules, I mean how can windows writte somethig specificaly to disc C or disc D.
In every programming language when you declare variable it gets saved into to the memory, and when you need to store something to hdd, you have to use some library.
So, how does windows handle it?
Does it treat all discs and memory modules as a single line of data, and does it only save each mediums beginning adress? - like 0x00000 is where the disc C begins, 0x15616 is where the disc D begins.
Like #MSalters said,
C: is a symlink to something like Device\HarddiskVolume1.
What it means is that disk drivers on Windows are implemented as virtual filesystems a bit like on Linux. I'll explain for Linux since there's much more documentation but the answer is quite similar for Windows even though both OSes do things differently.
Basically, on Linux everything is a file. Linux ships with disk drivers as these are at the basis of every computer. Linux exposes a driver model like every OS. The Linux driver model for files (including hard disks) exposes functions that will be called by the kernel to read/write to disk. There are open, read and write functions that the kernel expects to be present for a file driver.
If you wanted, you could write a disk driver and replace the existing one. You write drivers as modules that you can then load in the kernel using certain utilities that ship with Linux. I won't share more details as I'm not that much aware. Once your code is loaded in the kernel, it has access to all kernel code and all hardware since it runs in kernel mode.
Today, disk drivers probably use PCI DMA which is a controller connected to the PCI bus which allows to do disk operations which ignore the CPU and load disk data to RAM directly. The PCI convention says that all compatible devices (like PCI DMA controllers) must expose a certain interface to the computer. This interface is mostly some memory mapped registers that can be used to send commands to the controller. The OS will write data in these registers to tell the DMA controller to do disk operations. Then the DMA controller will trigger an interrupt once it is done. The OS will then know that the data is readily loaded into RAM and ready for use. The same applies for writing
The OS knows the location of these registers by looking in the ACPI tables at boot.
In modern Windows (2000 or later) C: is a symlink to something like Device\HarddiskVolume1. The number there can vary. Typically, \Device\Bootpartition is also a symlink to the same HarddiskVolume.
Windows doesn't use libraries to write to disk. Instead, it uses drivers. The chief difference is that drivers run as part of the OS kernel, while libraries run as part of applications.
Is there any OS that I can boot with a usb and then see whats inside the c drive and d local disk so that I can manipulate the files in
I tested many Small Operating systems but I never saw files or drives like C:/
Since you can mount NTFS and FAT32 drives with Linux, you can manipulate Windows files after booting a small Linux distribution like PuppyLinux or any other.
I also just read that KolibriOS can read those file systems, and it is 1.44MB large, surely one of the smallest graphical OS.
I have a client issue that I am working on with a stack of SSD drives and a machine that they were previously installed in. As of now, the stack of drives shows up in a few Operating Systems (Win10, Win7, Mac OSX) as an unpartitioned raw space. I am looking for a simple way to examine the drive and see if it is actually raw, or just formatted for ZFS.
Does anyone know of a Windows or Mac Utility that could help? I've tried a few recovery software programs, that hinted at being compatible with ZFS formatted drives, but have yet to see anything that would indicate if it was actually a ZFS, or simply not formatted.
Regards,
Ed
ZFS is storing at the start and at the end of each device a magic number, 0x00bab10c ("oobabloc", i.e. überblock), reversed for little-endian: 0x0cb1ba00.
So if this number doesn't appear in the device data, you can be sure it isn't used by ZFS. If it does appear, you need to investigate a little further.
For details, have a look to the ZFS on disk specification draft available here, especially page 13.
I have read that USB HDD are hot-pluggable but not removable whereas USB Flash drives are both removable and hot-pluggable.Internally, the windows DEVICE_OBJECT structure has Characteristics flag that can have a value FILE_REMOVABLE_MEDIA for removable media (not the removable device). Also, STORAGE_HOTPLUG_INFO structure has Devicehotplug boolean member that says device is hot pluggable or not. Can you please justify your answer with a little details?
David Zeuthen explains it best:
[...] "removable" means that the media of the device is removable. For
example, CD-ROM drives or Nin1 card readers for flash media. [...]
ATA disks connected via eSATA aren't removable, you can't remove the
platters.
Yet of course, you can intuitively understand that even non-removable devices can be hotpluggable (i.e. you can plug and unplug the entire device as a whole, as opposed to inserting/removing the media it contains).
Now, all (modern) buses in use in current systems are hotpluggable -
most new systems allow you to add/remove SATA disks while the system
is running.
Indeed you shouldn't have to care much about whether something is hotpluggable or not anymore: virtually all storage devices are. (In the past, you had to shutdown the machine to manipulate the storage devices).
So, it should follow that external USB drives (either HDDs or flash sticks) for example should be non-removable and hopefully always hotpluggable.
Unfortunately:
Of course, hardware sucks so virtually all USB keyfobs reports
"removable==1" probably because the maker of the device wanted to be
"helpful" and make things work better on windows.
I have no sources regarding the real reasons, but it turns out that many USB drives report themselves as removable too. David's suggestion that it might be because of certain operating systems which didn't use to support hotplugging but did support removable devices (CD-ROMs, etc) sounds reasonable: the manufacturers reused the same technique to trick the OS into letting the user "eject" USB drives.
Nowadays I would guess all modern operating systems make the distinction clear, and this has many advantages from a management standpoint (e.g. you might have a hotpluggable DVD drive with removable DVDs and you would thus need to be more clear about which you want to interact with). Still, older drives and old habits die hard, so you'll still find some "removable" USB drives even if they're really not.
Note: The bug report linked is about udisks which is more often found in the free software world. But again, I'm sure all systems make the distinction now even if the terminology is not exactly the same. Also note that the terminology is really rather arbitrary, though whichever terms you use for these two concepts best be well understood.
A simple Google search could have answered your question...
Hot plugging is the ability to replace or install a device without shutting down the attached computer. Hot plugging is implemented when
a peripheral device is added or removed; a device or working system
requires reconfiguration; a defective component requires replacement
or a device and computer require data synchronization. Also known as hot swapping. Hot swapping
allows easy accessibility to equipment and the convenience of
uninterrupted systems.
Removable media are data storage devices capable of computer system removal without powering off the system. Removable media devices are
used for backup, storage or transportation of data.
source: techopedia dot com
I am trying to read/write usb hard drives and flash drives for a DOS application.
I read EDD spec. and it mentions that function Int13(Fn = 48h) can be used to get interface path and device path for a particular disk drive. This also includes usb interface and ata interface.
Now this function also returns a Device Parameter Table Extension (DPTE) table that gives I/O addresses via which a software bypassing Int13h can use to read/write the device. But this table is only for ATA afaik.
I wanna read/write to usb disk/pen drives w/o using Int 13h. Is it possible?
Actually it is a disk I/O sensitive application in protected mode. So using Int13h would involve heavy penalty in terms of performance, due to mode switching. So, I am trying to avoid using Int13h.
Does bios initalizes usb drives to appear as ATA drives too. If so, then I can use DPTE to get the I/O base addresses of the command block and control block and then access the usb drives just like ATA drives. Am I right?
Thanks
This particular issue has been discussed at length among the FreeDOS community. The best guide to the whole issue is the FreeDOS technote "USB with DOS"