This will be the next challenge and the last will be how to do this within Windows and not through the DOS.
Well, there's a little problem with that. You'll have to rewrite this application from scratch and supply a device driver to pull this off. User mode applications do not have any access to the hardware, hence the need for a driver.
If you've got the complete specs for reading/writing the CMOS on a Gigabyte board, the ability to write and debug kernel mode code, specically device drivers, and can write said device drivers in C (cannot use C#!), you should be able to pull this off.
The basic Line Print Terminal connector (parallel port) pin function specifies pins 2 - 9 for data bits 0 - 7. So I suppose you need to make a distinction between the hardware and the software you might be using. with the hardware accepting 1 byte, buffer size in your software - whatever that is - is now the question you need to address.
i'm making a disk(volume) backup/restore system.
i would unmount volume before backup,
but the system volume can not be unmounted.
so the change or access of system volume is worry for me while that system volume is backup.
is it possible that detect which disk sector or ntfs cluster was changed realtime?
that can be filter driver, can it be possible?
So I have a driver that does a child enum on the ACPI PDO. It gets back the methods, and then does an evaluate. There are two ways of doing this, evaluateex and evaluate. Oddly for exactly the same methods they return different data, not different in value, but the ex evaluation data has a 4 byte padding after each package, the eval method doesent. This is for _PSS data.
What is also odd that if the eval is called during IRP_MJ_START_DEVICE the _PCT data is also different to that obtained later on so I assume even then the device hasnt completely started. The _PCT at IRP_MJ_START_DEVICE shows IO port access, but later shows FFHW as the acces.
What is also interesting is that attaching to the PDO outside of AddDevice causes enum children to returns STATUS_NOT_SUPPORTED, which is odd, since the only interface to the PDO is the PDO pointer and the Irp, how DOES the PDO know the Irp is being sent from a DO attached outside of AddDevice? Odd stuff indeed.
Anyway it doesnt affect the functioning of the driver, it controls COU speed OK, but this variability of what the PDO is returning is odd and I cant exmplain it. Anyone have any idea why this is?