How to bypass Windows 'cooking' the I/O? (One more time, please)

[norseman]

I know I saw the answer recently, as in since February '08, but I can't 
re-find it. :(   I tried the mail archives and such and my own 
collections but the piece I saw still eludes me.


Problem:  (sos=same old s...)  Microsoft insists the world work it's way 
even when the Microsoft way was proven wrong decades ago. In this case 
it's (still) 'cooking' the writes even with 'rwb' and O_RDWR|O_BINARY in 
(proper respective) use.

Specific:  python created and inspected binary file ends:
	   00460: 0D 1A        (this is correct)

	   after a write
			os.lseek(target, -1, 2)
			os.write(target,record)
	   the expected result would be:
	   00460: 0D 20 .....data bytes.... 1A

	   BUT I get:
	   00460: 20 .... data bytes... 1A

It is one byte off!!!  And the 0D has to be there. Signifies the end of 
the header.


Same python program runs as expected in Linux.  Maybe because that's 
where it was written?! :)


What I seek is the way to slap Microsoft up side the head and make it 
work correctly.  OK, well, at least in this situation.


Note: Things like this justify Python implementers bypassing OS calls 
(data fetch, data write) and using the BIOS direct. Remember, the CPU 
understands bit patterns only. It has no comprehension of 'text', 
'program', 'number', 'pointer', blah blah blah....  All that is totally 
beyond it's understanding. A given bit pattern means 'do that'. The CPU 
is 100% binary.  Memory, storage and the rest is just bits-on, bits-off.
Patterns. Proper binary I/O is mandatory for the machine to function.


Anyway - if whoever mentioned the flags and such to 'over ride' 
Microsoft's BS would re-send that piece I would be very appreciative.


Steve
norseman at hughes.net