Any ideas on how to exit the boot up version of basic on an old IBM XT - suggestions here don't work
If your old computer boots-up to ROM BASIC that means that there is no hard drive detected and/or no floppy drive with a boot disk. There is nothing for "system" to exit to.
You need to either check the connection on the hard disk, if it is indeed an XT model and not just a regular PC, or you need to get a 5.25" PC-DOS or MS-DOS boot disk.
Related
I am working on a project to replicate windows write requests from one hard disk to another in real time asynchronously.
I am new to kernel mode drivers development under windows, what I have in mind is to monitor IO requests.
I searched a lot but this area is not documented as it should.
I did my search and found 4 leads (but non of them is sure the best option to start with)
IRP
IO request packets used by windows drivers to communicate between them and the OS, but will I be able to monitor the IRP used by the hard disk driver ? and what about the security?
Windows filter drivers
there is a lot of system filter drivers levels from upper to lower, which one should be used? and Will I be able to filter the IOs used by the hard disk driver?
IO hooks
this technique is used by windows antiviruses to hook the IOs and check the files. Is it reliable to use in my situation ?
kernel event tracing
Used by Microsoft Diskmon tool to monitor hard disk activity.
The problem here is that I don't know where to start and what is the best option to start with in terms of performance and security.
you at first must perfect understand windows Storage, Volumes, and File System Stacks and use Device Tree
determinate which device you need filter, and as UpperFilter or Lowfilter. you really need replicate disk, or say partition(volume) on disk or file-systems read/write ?
for attach to device you can register self in registry, say for disk filter - under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318} in UpperFilters or LowerFilters
read this storage stack example
your place is at (4) (LowFilter - you will be filter IRP_MJ_SCSI for read/write) or (7) (UpperFilter - you will be filter IRP_MJ_READ/IRP_MJ_WRITE for read/write)
driver must be or direct WDM (register AddDevice in Driver) or use KMDF (shell framework)
another solution use IoRegisterPlugPlayNotification(EventCategoryDeviceInterfaceChange, &GUID_DEVINTERFACE_DISK) for attach disk FDO - here you always will be UpperFilter
and the best resource for ask this kind of question, advice - is osronline - NTFSD or NTDEV forum
I want to try programming for EFI so I created a VM using virtualbox, checked "enable efi" option and left CD empty.
The efi shell boots how it should but instead of FS0 i only see BLK0, BLK1 etc. Is there any way to have FS without inserting USB disk (which is displayed as FS)?
Edit:
Thanks for your replies. For people who still want to use VB - formatting VB disk with DISKPART using Windows CD solves the problem.
#unixsmurf answer in comments is correct. Your image need file system supported by UEFI. If you can't see fsX in output of map command then it means that non of attached block devices (blkX) contain supported file system. Please create FAT32 partition on your disk, then you will be able to see fsX in map output. To switch between file systems use DOS like syntax command ie. fs0: switch to FS0 file system.
According to UEFI specification 2.5 section 12.3:
EFI encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable
media.
I would suggest to use OVMF (Open Virtual Machine Firmware) directly with QEMU not through VirtualBox. Why ?
Because you can hack OVMF and learn how it works internally, this give you better understanding, VirtualBox hide internals and I'm not sure if it allow firmware replacement
OVMF was developed initially for QEMU and it is adapted by various other virtual machines, because of that there is much more support for OVMF on QEMU then OVMF on VirtualBox
using QEMU also give you ability to emulate your hardware and write drivers/applications in UEFI that use it
I wrote beginners tutorial that help setting up development environment needed for UEFI application development using OVMF.
More about OVMF.
On Windows (XP-7), is there a reliable way of programatically differentiating between USB floppy drives and USB flash drives in C++?
At the moment, I'm using WMI to get updates when new Win32_LogicalDisk instances are detected, and then using the DriveType attribute of the LogicalDisk object to figure out a basic type. This works quite well, except that floppy drives and USB flash drives are both of DriveType DRIVE_REMOVABLE, so to differentiate between those (floppy vs. flash), I'm using the IOCTL_STORAGE_GET_HOTPLUG_INFO interface to figure out if the device is hotpluggable, and was working on the principal that that meant it was a flash drive and not a floppy. Again, I think this works quite well (if a little inefficient, using both the WDK API and WMI to get info ) in the case of internal floppy drives, but unfortunately USB Floppy drives are also hotpluggable a lot of the time, so there is no clear way to differentiate between flash and USB floppy drives, that I can see. I know there are properties that may work, like checking if its mapped to the reserved drives A: or B (edit: only relevant if the machine definitely has a floppy drive - see MS-KB: How to change drive letter assignments in Windows XP), or looking at the description, but I'd really like something a bit more reliable.
Sorry about the long explanation, but just wanted to be clear! Thanks
Did you try Win32_LogicalDisk.MediaType? It has specific enumerations for floppy disks. Make sure you try it when there's no disk in the drive.
On the USB level, there is no way to differentiate between a conventional Disk on Key and a USB-Floppy. Which means windows itself, cannot tell reliably what is what.
There are a few hints that you can gather:
Floppies should:
a. Have mass-storage protocol CBI/CB
b. SCSI UFI
BUT, in the world of USB devices, everyone does whatever they want. The only test is: "Does it work on windows". And Windows just checks the size, if its a USB device with removable-media set and with conventional floppy sizes, it will consider it to be a floppy.
Can't say about "real" floppy, but with the USB attached, there is no definite way.
You can use the Size attribute (USB > 1.4MB), it's not like there is any chance of meeting 1.4MB flash drive any time soon.
The obvious property to check would be IOCTL_DISK_GET_DRIVE_GEOMETRY. This gets you (amongst other things) a MEDIA_TYPE. Anything but RemovableMedia and FixedMedia is a floppy.
For a full dev environment setup in a VM using VMware Workstation 7 with Visual Studio/SQL Server on XP, are there any major performance issues using the VM off a local drive vs USB drive to be concerned with?
Currently using it from a secondary local drive but considering moving to a USB drive so as to have it more portable so cna be used from a laptop when on the road and desktop when at the office.
Or is it better off copying the files as needed between machines onto the local drives?
You want to keep the VM files as close to the CPU as you can, especially for things like compiles that are going to be disk intensive. A local disk is best, a fast networked disk (1Gbs or better, 10Gbs) is good, and USB can vary.
VMs are easy enough to create and throw away, why not simply set it up and try it?
Try benchmarking it with something like HDTune. I'm sure there'll be a noticeable performance hit, but whether it's bearable or not you'll probably want to just try it.
With local vs. USB, the drive speed itself will probably be the biggest factor in speed. With NFS or SMB you still want a fast disk, but lots of small reads and writes will have more latency than with the direct attached methods.
BTW, this really doesn't have much to do with VMware, the advice holds true for compiles on the host as well.
I'm using a barebones tutorial as the basis for an OS I'm working on, and it seems to be an older tutorial: it has be compiling the kernel down to a floppy image, and then loading it with GRUB.
Basically, I still want to use GRUB, but I'd like to have my OS run from a CD instead. The main reason is that I don't actually have a real floppy drive available (I'm testing in VirtualBox currently) and I thus have no way to test my OS on real hardware.
I've been poking around on the net, and I can find lots of utilities that create a bootable CD from a floppy image, but these all seem to require an actual floppy drive, plus it's not really what I'm looking for. I'd like to be able to end up with a bootable CD during my make step ideally, without needing to first place the image on a floppy, which seems rather pointless.
I guess the easy way to answer this: How do I set up GRUB to read my kernel image from a CD? Will I need a special utility to do this from Windows? (The kernel can't compile itself yet, that's not for a looong while)
Thanks!
I found the solution for my project on my own, with some advice from the folks over at OSdev. There is a utility called mkisofs (which can run under Windows using a cygwin dll) that takes a directory, and makes that directory into an ISO image that can be burned to a CD. Using the -b flag, you can specify which file should reside in the boot sector of the disk.
The solution is just to have GRUB in the bootsector, and use GRUB to load the kernel image, which I can compile out in non-floppy form easily.
AFAIK a bootable CD is pretty much the same as a bootable floppy. You need to put the boot loader (GRUB) into the boot sector etc., the BIOS will take care of the low level stuff until you switch to protected mode.
You will probably have to make your image and then dd it to the actual physical disk.
Here's the El Torito Bootable CD specification:
http://www.phoenix.com/NR/rdonlyres/98D3219C-9CC9-4DF5-B496-A286D893E36A/0/specscdrom.pdf
EDIT: An alternative way to test your kernel would be a bootable USB stick. Again, the BIOS will take care of the low level USB stuff until you turn on A20 and jump to protected mode.
If you're interested in looking at code, then the Moblin Image Creator is probably a good application to check out. It's written in python and can create different types of bootable images (CD, USB and NAND) for both Live and installable configurations of Moblin Linux.