My name Is Michael i'm writing you with the hope that you'll be so kind to give me some advice or just to direct me to the place that someone can help me.I'm working on my project that unfortunetly untill now i can't finish.I'm stucked in the place that i dont know how to get out and find solution. I'm surching for information over the Internet already about 2 months typing any kind of key-word in google and chating with people that stand to be a programmers and so on, and so on but nothing it seems that, like someone wants me to give up but I say no. Its about a program that loads itself before the OS-in my case Win98 and hooks itslef in int13h substitute the original int13h with itself.My problem is that this program reads and modifys all the data that is taken from the hdd trough int 13h and then gives back the control to the program that made the call. Its exactly like this:CALLER(PROGRAM-OS-WIN98[io.sys]) <=>MY_INT13H(Extended Read)<=>INT13H(BIOS Extended Read)<=>HDD. The problem first occur when io.sys loads itself from hdd and executing itself from RAM ->I'm Monitoring the buffer that contain the data taken from hdd and its fine until its reach assume this is point 2-Using Extended Read (Multy Sector Read >1 sector).So io.sys request ExtRead(8-sectors).BUT here the data in the buffer is not actualy taken from the physical surface but from somewhere else(unknown to me) where this data is saved in modifyed state.I figured out that this is the same data that was readed before but using Myint13h ExtRead (1sector) and i think that io.sys save that data in some kind of buffer or cache when it get back its request to int13h(My).But how the original int 13h takes and why it takes that data from there first before it takes it from the physical surface??? I know that my explanations are pretty bad but i hope that you will get the essential of the problem. Also in addition of the above the data that is not taken from the physical surface is only 256bytes from the one that has been taken from from previouse call to Int13h(My 1sector). Thank you very much for your attention! THANK YOU! Maybe this is some kind of cache but why it decide to put data in this cache when myint13h returns the data to the caller?Why? Thank you and sorry for interrupting you. Best Regards Michael Dervahanian

I don't know if this is involved, but what of the cache on the drive itself. I don't know if there is a command to flush that cache, otherwise successive read commands to the same location should retrieve the same data.

I think that hdd-cache is involved but how io.sys change it?Is there any way to understand when the data is taken from the physical surface and when from some kind of cache/buffer??? Bug

That early in the boot sequence there shouldn't be any caching or anything going on. int 13h should always read from the disk itself. Once windows gets into protected mode it isn't even calling int 13 at all, is it?

Normally I think the drive cache runs independently of the OS. It just compares the contents of the on board buffer with the last read request. If the data is within the last read, it just returns the data, otherwise it does a seek to get the data. There is also the OS buffer to contend with. I think if there is a write pending the action is/can be much more complicated. Example, if the OS does elevator seeks as the head moves over the tracks, reads and write occur as the head passes over the tracks. This increases throughput with the added overhead that the OS must cache multiple requests. This action is necessary in true multi-user systems where there is many almost simultaneous read and write requests.

Well i see what you people think,but the results are diffrent.When IO.SYS loads itself end SIMULTANEOUSLY executs itself from RAM,that problem occurs every time. I wonder too why if this problem is because of the hdd cache why it decide to put there the data returned from myint13h,why???If this cache runs independently of the OS like Wizard-Fred stand to be,it is logical that it will put data there when it reads some data from the physical surface,NOT when int13h returns the data to the caller,right???Yes but the results shows that it is not like that.At a certain moment of the loading a call to myint13->originalint13h->hdd.. gives back data that is not in any way on the hdd.The data is like someone has rearranged the data in the hdd cache and then int13h gets that data in the state that this someone wanted to.I dont know why?Also in addition of all this more exact, this problem happens when the 3th sector of the io.sys that should contain the code of it is loaded from hdd.BUT here !!!This sector is not from io.sys,and i think io.sys is not only 1024 bytes right:) Whell the only way is that this code to be from command.com only there I found [cd 13]hex value that is loaded i havent yet complete the examination but i dont see where this code can be anywhere else-'cause there are only 3 files ont the hdd and msdos.sys contain only text information for compatibility like microsoft says.So people what you think??I do disassembler of this 3th sector,but I cant figger out what this code is doind.I sow that it uses DMA but this cant be something that occurs our problem. Thanks Michael

Ok, I'm kind of confused as to your actual problem... is this correct: computer boots, hits the drive, loads the boot sector. Boot sector grabs io.sys, loads it. From now on, calls to the hard drive return data from different sectors than they should. You're right, DMA shouldn't have anything to do with this, DMA only manages the transfer from disk to memory. The programmer tells the disk what sectors to load. I'm still not sure I understand though... is this myint13h YOUR function? Where did it come from? How do you know it's there? If you could detail the situation a bit more it might help. Is this in an operating system YOU are writing? Or just a strange problem? or what?