Atari ST , TOS DOCs, literature, WEBsite errors

[Petari]

Yes, it is sad to see how many errors are present in official Atari DOCs about Atari ST machines, TOS . And diverse books published in years when Atari ST was used a lot (as main computer, so in 80-es, early 90-es).
And of course big part of errors was never corrected, instead it they went on WEB pages, in forums.

Will start with error in Atari ST ProfiBuch edition from 1987, what I have. So, it appeared that Fwrite Trap #1 ($40) TOS function works not in Hatari when file was opened with mode 0 for Fopen Trap #1 call ($3D) .
I admit that I was not aware of it until yesterday, when JY e-mailed me about that.
I looked in my ProfiBuch, and there is added 'comment' by me, by handwrite:  ?? Wrong!
I even forgot about it. As I never had problems to perform write when file was opened in mode 0 (read only).
Well, here to say that whole thing has no sense. If SW won't allow write to file, just don't use Fwrite function. File access permissions are defined by Fcreate function, btw.

Since I use Steem 3.2 mostly, and in big part with GEMDOS hard disk emulation (what means that emulator handles it in big part - mostly via intercepting related Trap #1 calls in running SW). And there it works as with real HW considering Fopen mode. And of course with real hard disk emulation too (via pasti.dll).

I made simple test SW for this problem. Fopen test programs
Note: if you see message about potential risk when DL above - I guess this is because some morons wrote somewhere about my 'harmful' SW . Just ignore it.
Too bad that such things can even happen without any testing of that SW, what someone just 'reports as bad' . But this are such times. Great gmail (used by many millions) just blocks e-mails where some file with extension IMG is present (in ZIP archives too). No any content check - so, if rename it to like IMW, it passes :-)  Really ? And they are even paid for making 'filters' ...  Or even more silly case: some German e-mail service rejected e-mail because ZIP attachment was very well packable - sure it was, empty floppy images are such (98% of content is same bytes) - I laughed for some minutes after seeing it :-) Bunch of lazy ... hmm, who is really lazy - employees or their bosses ? Answer is easy: both .

And yes, mode 0 results in write error - tested with Hatari 2.1.0 and 2.4.1 (Win versions) - but not when running from real emulation of hard disk (ACSI) - then is OK - of course, because then it is handled via TOS.
Only in GEMDOS hard disk emul. is write error (actually it's just disabled then by Hatari).
Well, this is just another case when they went on doing it according to DOCs instead according to how it happens in reality.
And will this be corrected in Hatari ? Why should ... DOCs are good, PP is wrong :-)  Yep, welcome to Atari ST 'community' . 
OK, I hope that this will help some people, and that's what matters.

More DOC errors soon ...